#1644 Packaging fixes for Modularity/Base Runtime
Closed: Invalid 7 years ago Opened 7 years ago by psabata.

When building the initial, self-hosted Base Runtime prototype we encountered numerous package build failures, often caused by more or less trivial packaging errors such as missing [build] dependencies.

Our buildroot is somewhat different from the standard F2[3456] buildroots and we therefore run into issues package maintainers normally don't.

Even though the current Packaging Guidelines already mandate that packages [build]require all their dependencies, having FESCo's blessing for implementing packaging fixes to resolve these issues would be helpful.


We already have similar concepts for things like Alternative Architectures, and we also have provenpackager. Could you elaborate more on what exactly you're looking for FESCo to do/provide here?

(As an aside, I thought Base Runtime was intentionally NOT self-hosting.)

@jwboyer I'm looking for an official statement from FESCo that the seemingly random packaging fixes are fine and approved, something we can point to in the (provenpackagers') commit messages, for example.

Base Runtime, as delivered to the end users, won't be self-hosting, indeed. However, the Modularity/Factory2 infra isn't bootstrapped yet and to build the initial prototype, as well as any later updates and post-split small-ish modules, we need the first module to have that quality.

@jwboyer I'm looking for an official statement from FESCo that the seemingly random packaging fixes are fine and approved, something we can point to in the (provenpackagers') commit messages, for example.

No, I'm not OK with "seemingly random packaging fixes". That's completely the wrong approach to the problem you are trying to solve.

What I would support would be clear, accurate descriptions of the changes in the commit logs with documented reasoning as to why the change is necessary. If it has a bug attached to it, even better. The more information we have for a change, the less likely it will be undone because people don't understand it and the better chance it has of carrying through to other downstream consumers like RHEL.

Base Runtime, as delivered to the end users, won't be self-hosting, indeed. However, the Modularity/Factory2 infra isn't bootstrapped yet and to build the initial prototype, as well as any later updates and post-split small-ish modules, we need the first module to have that quality.

OK.

When building the initial, self-hosted Base Runtime prototype we encountered numerous package build failures, often caused by more or less trivial packaging errors such as missing [build] dependencies.

I am interested to look first into what kind of these build failures are. Do you have a link of packages that failed to build due to missing BuildRequires?

Our buildroot is somewhat different from the standard F2[3456] buildroots and we therefore run into issues package maintainers normally don't.

So does this mean the spec files that we have for rpms/somepackage when gets fixed will also be fixed for Modularity/Base Runtime?

Even though the current Packaging Guidelines already mandate that packages [build]require all their dependencies, having FESCo's blessing for implementing packaging fixes to resolve these issues would be helpful.

I must be missing some context here but if there is some need to improve packaging of some package then why not first file a bug against that package, request to allow to commit fix and commit it. I am trying to understand why FESCo is needed for this issue? I see this as a general packaging issue and any provenpackager can come forward and fix it.

@jwboyer

No, I'm not OK with "seemingly random packaging fixes". That's completely the wrong approach to the problem you are trying to solve.
What I would support would be clear, accurate descriptions of the changes in the commit logs with documented reasoning as to why the change is necessary. If it has a bug attached to it, even better. The more information we have for a change, the less likely it will be undone because people don't understand it and the better chance it has of carrying through to other downstream consumers like RHEL.

Somehow, I was expecting this to be a standard practice without an explicit need to be mentioned. Yes, the commit messages would, besides linking FESCo's blanket approval that explains the motive, describe the changes and why they're needed.

My expectation is we would exercise our provenpackager rights to do this to a) speed things up, b) avoid unnecessary bureaucracy overload. However, if accompanying bug reports are required, we could certainly file them, too.

@pnemade

I am interested to look first into what kind of these build failures are. Do you have a link of packages that failed to build due to missing BuildRequires?

Yes, there are hundreds of them. Many are related to the no-more-perl-in-the-standard-buildroot change but not all of them, some were caused by incorrect module packaging, others failed for various other reasons. I haven't fully investigated it yet.

http://koji.stg.fedoraproject.org/koji/builds?start=0&userID=modularity&order=-build_id&state=3

So does this mean the spec files that we have for rpms/somepackage when gets fixed will also be fixed for Modularity/Base Runtime?

Yes, indeed. The modulemd files ("SPEC files" for modules) reference RPM sources in dist-git.

I must be missing some context here but if there is some need to improve packaging of some package then why not first file a bug against that package, request to allow to commit fix and commit it. I am trying to understand why FESCo is needed for this issue? I see this as a general packaging issue and any provenpackager can come forward and fix it.

See my response to Josh above. Having FESCo specifically approve these changes would, while not strictly necessary, make our interactions with the primary package maintainers easier.

@jwboyer

No, I'm not OK with "seemingly random packaging fixes". That's completely the wrong approach to the problem you are trying to solve.
What I would support would be clear, accurate descriptions of the changes in the commit logs with documented reasoning as to why the change is necessary. If it has a bug attached to it, even better. The more information we have for a change, the less likely it will be undone because people don't understand it and the better chance it has of carrying through to other downstream consumers like RHEL.

Somehow, I was expecting this to be a standard practice without an explicit need to be mentioned. Yes, the commit messages would, besides linking FESCo's blanket approval that explains the motive, describe the changes and why they're needed.

I thought it was standard practice too, but you went to the trouble of opening this ticket and then used language that implied it wasn't. We need to be very clear in our intentions and communications so that expectations are set appropriately. It is better to be explicit than assume.

My expectation is we would exercise our provenpackager rights to do this to a) speed things up, b) avoid unnecessary bureaucracy overload. However, if accompanying bug reports are required, we could certainly file them, too.

I view the bug report as nice to have for history and notification of the primary maintainer. If the notification aspect can be done without bugzilla, and the dist-git commit logs are detailed, then the bug might not be necessary.

I must be missing some context here but if there is some need to improve packaging of some package then why not first file a bug against that package, request to allow to commit fix and commit it. I am trying to understand why FESCo is needed for this issue? I see this as a general packaging issue and any provenpackager can come forward and fix it.

See my response to Josh above. Having FESCo specifically approve these changes would, while not strictly necessary, make our interactions with the primary package maintainers easier.

Yes, but the interactions still need to be had.

See my response to Josh above. Having FESCo specifically approve these changes would, while not strictly necessary, make our interactions with the primary package maintainers easier.

Some people, including myself, do not appreciate when someone goes over their head instead of approaching them directly first. If your commits are sufficiently documented and justified, there should be no issue with them being accepted by the respective maintainers. I don't think involving FESCo in this manner is helpful at all. Speaking with my maintainer hat on, if you were to push commits to the packages I maintain without a clear explanation but with a message "approved by FESCo" instead, I'd be furious. In my opinion, you should either file bugs with patches attached and sufficient explanation saying you'll commit the patches in a week or contact the maintainers in some other way (e.g. e-mail), conveying the same message.

Well, we already have a place where we can discuss things like this: The devel list. :)

I'd say create a list of affected packages with acl holders (so someone can look up what packages they can fix), explain the issue and how to test after fixing on the devel list, then after some time make another run and tell people you are just going to go fix those if they aren't fixed by $date and do so.

If there's a clear case of why the changes are needed, a chance for maintainers to fix their own packages, a way to test that they are fixed and a deadline I think most maintainers would be happy.

I saw few build failures due to missing perl(Data::Dumper) dependency but I think this can be easily solved by adding it as Requires: in autoconf package instead of adding it to every other package using BuildRequires: autoconf

I think, given that no action is planned here, this ticket can be closed.

FYI, I attempted to rebuild a set based on RC3 data and the number of failures is much smaller -- mere 152 packages failed to build, for varied reasons. We're now analyzing the logs and I'll mail the devel@ list once we have some more data. We'll also file a bug for each individual failure, if applicable (some might be caused by a broken dependency, similar to that autconf breakage in the previous run).

@sgallagh changed the status to Closed

7 years ago

Login to comment on this ticket.

Metadata