#8582 "Adding package.cfg file" commit
Closed: Fixed 3 years ago by amoloney. Opened 4 years ago by ellert.

Hi!

I tried to reopen https://pagure.io/releng/fedora-scm-requests/issue/14785, but it was automatically reclosed again without anyone answering my questions. So I now open a new issue instead hoping fir o more pleasant experience.

I restate my questions below:

Why is there a "Adding package.cfg file" commit on this branch?
What is its purpose?

I find this commit very disruptive and would prefer it not to be there, can someone please remove it?
What mistake did I do to trigger this commit to be added?


This is definitely a bug. I am not sure where, but I guess in fedscm-admin tool.

Ah, already fixed upstream: https://pagure.io/fedscm-admin/c/b5976d1ae92184f1f1f9ee1c7f69916d5e624883?branch=master

@limb can you make sure to use fedscm-admin with this patch?

Will do. Any updates on my PR?

Huh. I think mine does have it actually.

Do I understand it correctly that this commit shouldn't have happened on an epel 7 branch, but that such a commit would have been expected on an epel 8 branch? It would be equally disrupiive there...

Can the commit be removed since it was added in error?

Do I understand it correctly that this commit shouldn't have happened on an epel 7 branch, but that such a commit would have been expected on an epel 8 branch?

Yes.

It would be equally disrupiive there...

How/in what way? It's needed in epel8 branches to keep epel8 and epel8-playground builds in sync (until/unless you decide to diverge them)

Can the commit be removed since it was added in error?

No, we don't remove commits. You can just remove it in a further commit.

It would be equally disrupiive there...

How/in what way? It's needed in epel8 branches to keep epel8 and epel8-playground builds in sync (until/unless you decide to diverge them)

It completely breaks the normal package maintenance workflow.

The traditioanal way to maintain a simple package that can use the same spec for all releases is to keep all branches in sync. That is, commit changes to master and merge master into the other branches. Occasionally a proven packager or releng slightly inconsiderately would add a commit to a non-master branch. The maintainer then needs to recover by merging this commit from the branch into master and then from master to all the other branches.

This way of cleaning up would not work for this "package.cfg" commit, since it would add a config.cfg file that is very branch specific to all the other branches. This is what I mean with disruptive. In order to recover here, the maintainer would have to first add a revert commit on the epel branch and then merge the epel branch to master. But what was the point of adding the commit then, if the first thing that must be done is to revert it.

Why would you ever need to build anything for playground if it is "in sync" with the non-playgrouynd build. The only time you need to build for playground is if it is different in some way, so you only need to build for playground if it is not "in sync". So there is never any need for keeping the playground build in sync with the non-playground build - so the package.cfg file solves a non-existing problem. Why add it then?

The workflow you are describing is not universal and some maintainers would find it completely antithetical to what they do. Even people who keep the same spec file are not looking to keep every branch 1:1 in order. What you seem to be describing is that you really don't want your software ever branched (since you find other people adding fixes to other branches inconsiderate) and just want 1 tree to work from and track. However that may be me putting words in your mouth.

In any case, I am not sure what you are wanting. No one to touch your branches ever? Some other solution? If that is the case, I would say you need to bring this up with FESCO as they need to clarify what we can do in EPEL branches in the future.

From what I understand the purpose of the package.cfg is to make it possible to build packages for the epel-playground repo from the epel branch.

If you are not going to build for the epel-playground repo, you then should remove the file to make sure there are no accidental builds done for the epel-playground repo.

If you are going to build for the epel-playground repo the reason for this is that the package in epel-playground is different from the package in epel, and should be built from different git branches, and you should remove the package.cfg file to make sure that all builds for epel-playground repo are done from the epel-playground branch, and not accidentally from the epel branch.

So in neither case the package.cfg file is useful.

The idea was that it should by default build against both el8 and el8_playground. This way a person can enable el8_playground and get as many packages are in el8.

This was to deal with the times when EL-8.n comes out and we aim playground against the latest and the regular el8 against the last el8.n-1 repo. That way a mass rebuild or some other problem could be done in el8_playground as we could find all the packages needing it versus trying to cherry pick what problems might happen as we have with former epel releases.

I am not saying this is the one way to accomplish this but this was what we found to be workable at the time. If you have a better solution, please let us know.

You plan is to use the epel-playground repo for two very different and incompatible tasks.

The first usecase is as a playground where maintainers can try out new versions and new features. This means that the versions of packages in the epel-playground are allowed to be different from the versions in epel, might have additional features enabled that the versions in epel are missing, and occasionally could even be backward incompatible with the version i epel or have a different soname for libraries.

The second usecase is as a place to do mass rebuilds for new rhel point releases, where you plan to change the rhel base to a new point release in epel-playgroind, do the rebuilds in epel-playground, and the when you change th epel repo to the new point release merge the mass rebuilt packages back to epel. But, since the use case for the playground repository was to be a place where new unstable stuff is tested, all those rebuilds will have been built against these new versions and might depend on features that are not provided by the dependencies that are in epel, or be compiled to depend on a different soname than the library that is available in epel.

I.e. since the playground is a playground, packages built in the playground must never be merged into main epel.

In Fedora there are rebuilds all the time. For new python versions, for new perl versions, and the recurring mass rebuilds. These are done in side tags. This can be done without adding a package.cfg file allowing the build of the package in the side tag, but koji allows this by default.

The proper way to do a mass rebukd for epel8 is to declare an epel8-rebuild sidetag that inherits from the rhel 8.n+1 and epel8 and definitely must not inherit from epel8-playground. The packages built in this sidetag can then be safely merged into epel8, when epel8 is redefined to inherit from rhel 8.n+1. And since it is a sidetag there should be no need to add any special package.cfg since this is not needed for sidetags in fedora.

OK at this point I think having this conversation in a ticket is not going to help get the viewing it needs. Could you please bring this up on the epel-devel list so we can get a wider view of the problem and resolve it.

Metadata Update from @amoloney:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata