redhat-rpm-config does not use a separate upstream repository like every other Fedora package As a result: 1. its source structure is completely insane, we’re >< that close to needing four-digit numbers to identify source files 2. cp -p %{sources} . is cute but really, that’s just a workaround 3. it triggers bugs in Fedora infra: I need to add some spec file examples to showcase the use of some complex macros provided by the package, but right now that puts them directly in the src.rpm, and copr will pick them up instead of the main spec file when rebuilding src.rpms 4. if I rename the files to make copr happy, that will break syntax highlighting in text editors and scm frontends Please rehost the files properly on pagure.io, gitlab, github or whatever, so they can be organised in a proper directory structure, and you can drop the 80% of the redhat-rpm-config spec file devoted to workarounding this lack of upstream project and structure. The project can be renamed at the same stage to follow Fedora naming conventions (https://bugzilla.redhat.com/show_bug.cgi?id=1655321) It will all remove friction within Fedora and make it something people can take example from instead of something they should absolutely not emulate
NAK. The traditional upstream model is HIDEOUS for redhat-rpm-config. How do I know? Because that's the way it used to be for several years, and it only grew into horrors like this: https://src.fedoraproject.org/rpms/redhat-rpm-config/tree/f20 - a slithering snakepit of patches on top of patches tangled in an incomprehensible mess. It's not a normal piece of software and the regular model just doesn't make any sense there, the way it is now does.
FWIW, if the redhat-rpm-config model feels cumbersome for the forge-macros, perhaps it means the model doesn't work for *them*, and that those macros should be hosted + maintained differently and separate of redhat-rpm-config. I have no clear recollection but it might have been me who asked the forge-macros to be included in redhat-rpm-config. And perhaps that was a mistake. The redhat-rpm-config content is fairly different from most of the other foo-macros stuff.
We have an open releng request to improve support for similar packages: https://pagure.io/releng/issue/7498 Ideally, we would go one step further and not even have to update the commit hash in dist-git.
(In reply to Panu Matilainen from comment #1) > NAK. > > The traditional upstream model is HIDEOUS for redhat-rpm-config. How do I > know? Because that's the way it used to be for several years, and it only > grew into horrors like this: > https://src.fedoraproject.org/rpms/redhat-rpm-config/tree/f20 - a slithering > snakepit of patches on top of patches tangled in an incomprehensible mess. That just means you need to actually release a different major for each maintained Fedora release, with major-specific branches, that can get separate commit updates, and so on. Really it's not rocket science, every Fedora project manages it fine, that’s what you’re doing today in the src.fedoraproject.org repo except it messes up other infra tools because 1. they do not expect to have project files in there 2. it’s a flat directory structure so everything on on top of everything else
(In reply to Florian Weimer from comment #3) > We have an open releng request to improve support for similar packages: > > https://pagure.io/releng/issue/7498 That’s funny that’s exactly what the forge macro do today for pretty much every hosting service except pagure (because pagure does not support tarball autogeneration) The workflow is 1. do changes in the upstream repo in whatever branch you like, 2. tag the result with the correct release number, 3. and then just bump this number in Version in the src.fedoraproject.org spec and launch a rebuild
(In reply to Nicolas Mailhot from comment #5) > (In reply to Florian Weimer from comment #3) > > We have an open releng request to improve support for similar packages: > > > > https://pagure.io/releng/issue/7498 > > That’s funny that’s exactly what the forge macro do today for pretty much > every hosting service except pagure (because pagure does not support tarball > autogeneration) > > The workflow is > 1. do changes in the upstream repo in whatever branch you like, > 2. tag the result with the correct release number, > 3. and then just bump this number in Version in the src.fedoraproject.org > spec and launch a rebuild Even if this were so, steps 2 and 3 do not add value here and significantly add to the cost of simple changes. And surely you still need to upload the upstream tarball to the lookaside cache? That's two more steps, I think.
In reply to Nicolas Mailhot from comment #4) > > That just means you need to actually release a different major for each > maintained Fedora release, with major-specific branches, that can get > separate commit updates, and so on. Oh yes it sounds nice and simple that way, doesn't it? Been there, tried it, it never worked on redhat-rpm-config at all, no matter who was maintaining it. It just doesn't. We know it's different from everything else, and it's that way very much *on purpose*. I'd ask that you trust 10+ years worth of numerous different people's experience with this hairball a little bit. After years of pain and misery, this is the first model that does, makes sense and is in fact pleasant to work with. > > Really it's not rocket science, every Fedora project manages it fine, Maybe the difference is that this is *not a project* that is developed in any traditional sense. It's a pile of settings that describes how the rest of the distro should be built, and this is the only sensible upstream for it. Like said, if this model doesn't make sense for something then maybe that something should live elsewhere then.
(In reply to Florian Weimer from comment #6) > (In reply to Nicolas Mailhot from comment #5) > > (In reply to Florian Weimer from comment #3) > > > We have an open releng request to improve support for similar packages: > > > > > > https://pagure.io/releng/issue/7498 > > > > That’s funny that’s exactly what the forge macro do today for pretty much > > every hosting service except pagure (because pagure does not support tarball > > autogeneration) > > > > The workflow is > > 1. do changes in the upstream repo in whatever branch you like, > > 2. tag the result with the correct release number, > > 3. and then just bump this number in Version in the src.fedoraproject.org > > spec and launch a rebuild > > Even if this were so, steps 2 and 3 do not add value here Step 2 and 3 mean upstream and downstream changes are cleanly separated, so your changes can be consumed by other distributions without being stashed away in a Fedora-specific repo no one else uses. It also means you can work on packages you are not the official maintainer of, without polluting the official spec with your private rebuild attempts. I don't think reducing downstream work to bumping a reference, then spectool + mock/koji/whatever you like is too much to add (you can even script it if your downstream workflow is always the same)
(In reply to Panu Matilainen from comment #7) > Like said, if this model doesn't make sense for something then maybe that > something should live elsewhere then. It does not make sense for copr, so maybe we should build a new infra to accommodate redhat-rpm-config maintenance model quirks?
(In reply to Nicolas Mailhot from comment #8) > (In reply to Florian Weimer from comment #6) > > (In reply to Nicolas Mailhot from comment #5) > > > (In reply to Florian Weimer from comment #3) > > > > We have an open releng request to improve support for similar packages: > > > > > > > > https://pagure.io/releng/issue/7498 > > > > > > That’s funny that’s exactly what the forge macro do today for pretty much > > > every hosting service except pagure (because pagure does not support tarball > > > autogeneration) > > > > > > The workflow is > > > 1. do changes in the upstream repo in whatever branch you like, > > > 2. tag the result with the correct release number, > > > 3. and then just bump this number in Version in the src.fedoraproject.org > > > spec and launch a rebuild > > > > Even if this were so, steps 2 and 3 do not add value here > > Step 2 and 3 mean upstream and downstream changes are cleanly separated, so > your changes can be consumed by other distributions without being stashed > away in a Fedora-specific repo no one else uses. It also means you can work > on packages you are not the official maintainer of, without polluting the > official spec with your private rebuild attempts. There is no such upstream/downstream separation for redhat-rpm-config. Even in general, the split does not offer much value. To my knowledge, no one builds a distribution based on Fedora and reviews the Fedora downstream patches before importing the Fedora package. I also don't understand your comment about non-maintainer work. The distant goal is to have a buildable Git checkout, as today, but without a lookaside cache and separate patch files. > I don't think reducing downstream work to bumping a reference, then spectool > + mock/koji/whatever you like is too much to add (you can even script it if > your downstream workflow is always the same) Your are contradicting yourself. If package-specific scripts are needed, then there's automatically a serious obstacle to non-maintainer work on packages.
I will point out that I had previously tried to provide a repository for RPM macros separate from this package (in fedora-rpm-macros) but this was not well received. I can certainly help to move the forge macros out to a separate package if that would make things easier for those involved.