#1350 Updates Policy should require inter-dependent packages be submitted together
Closed None Opened 6 years ago by adamwill.

= phenomenon =

Updates to inter-dependent packages are often submitted individually. This can result in broken dependencies (whether enforced by package management or not) and a poor experience for Fedora users.

= reason =

There is no obvious policy requiring inter-dependent packages be submitted together; I don't see it in https://fedoraproject.org/wiki/Updates_Policy , at least, or any other obvious place.

Until recently I don't believe there was a good guide to this either, but I've just written one (well, you decide if it's good, but it's one :>): https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages

= recommendation =

The Updates Policy should require that inter-dependent packages be updated together in internally consistent multi-package updates.


If that becomes mandatory then I recommend also providing guidance on how to find provenpackagers to add packages with different maintainers to a single update. (Even if that guidance is simply "ask for help on the devel list.")

It's been fairly common practice for groups that have this issue (such as FreeIPA and its attendant packages) to nominate one or two of their members for provenpackager status specifically for this purpose.

Of course, nowadays we have new groups in pkgdb2 that we could use for this purpose and avoid granting full provenpackager powers. (Best of all, the groups are self-managed).

I propose that we build into this update guideline a description of how to request the creation of a multi-package organizational group that can then be used to handle multi-package updates.

Of course, we'll still need a process to locate a provenpackager for those exceptional cases when a rebuild due to ABI breakage happens or something like it.

Before (or I guess at the same time) we draft a new policy/guideline, we should probably define what "inter-dependent packages" means. There are often cases where some new dependency is added on a specific version of a package and those should arguably go out together, but after that initial bump the packages can be updated independently the rest of the time. For those cases, it's often simple enough to ship the specific version of package X first.

So which specific case(s) prompted this ticket, and what would a proposed guideline/policy actually aim to address?

sgallagh: I would suggest that practical instructions should go in https://fedoraproject.org/wiki/Package_update_HOWTO and not in the Policy. The Policy can link out to the HOWTO , of course.

I do agree that we need to make it easier to actually achieve multi-package updates, and I sort of suspected that filing a ticket like this would trigger some update on that.

jwboyer: I consider it to be a per-update thing. That is, 'inter-dependency' is not an attribute considered to be held by a package in the general sense ('gedit') but by a particular build of a package ('gedit-2.0-3.fc21').

The test should be: If a given package build or set of builds were to be added to the current stable package set, with no other changes, would that cause there to be new dependency problems (in the strict RPM sense, or in the sense of broken behaviour caused by what is clearly a 'dependency'-type issue) in the notional combined package set?

If the answer is 'yes', that build or set of builds is not acceptable as an update as-is. The package or set of packages in any given update must pass the test.

Replying to [comment:4 adamwill]:

sgallagh: I would suggest that practical instructions should go in https://fedoraproject.org/wiki/Package_update_HOWTO and not in the Policy. The Policy can link out to the HOWTO , of course.

I do agree that we need to make it easier to actually achieve multi-package updates, and I sort of suspected that filing a ticket like this would trigger some update on that.

jwboyer: I consider it to be a per-update thing. That is, 'inter-dependency' is not an attribute considered to be held by a package in the general sense ('gedit') but by a particular build of a package ('gedit-2.0-3.fc21').

The test should be: If a given package build or set of builds were to be added to the current stable package set, with no other changes, would that cause there to be new dependency problems (in the strict RPM sense, or in the sense of broken behaviour caused by what is clearly a 'dependency'-type issue) in the notional combined package set?

If the answer is 'yes', that build or set of builds is not acceptable as an update as-is. The package or set of packages in any given update must pass the test.

OK. Don't we have an autoqa check thing for this already? So shouldn't we make that passing mandatory for all updates to avoid this?

I'm looking for something we can concretely implement and enforce here. Otherwise we're just talking about stuff people should already be doing and writing it on a wiki page.

jwboyer: heh, ironically, I was just going through the autoqa logs looking for example cases, which is handily illustrating the problem with that. It's nothing new - we've always wanted to enforce those tests, and never been able to, because the implementation isn't good enough. Quite a lot of depcheck errors are false negatives. It 'fails' whenever a package has an explicit conflict with another package, which is just wrong. It also tends to trip up on packages with 'interior dependencies' - dependencies between its own subpackages; it quite often fails complaining that a subpackage from the existing repo has dependency errors against the main package (or another subpackage) from the 'pending' (i.e. package set under test) repo, which it obviously shouldn't be failing on because all the subpackages will be pushed together.

Having said that:

"I'm looking for something we can concretely implement and enforce here. Otherwise we're just talking about stuff people should already be doing and writing it on a wiki page."

writing it on a wiki page is exactly what I want us to do. How are people to know they 'should already be doing' something if we don't write it down in the Updates Policy, which is the document that defines what people 'should be doing' in updates?

Writing it in the HOWTO is fine, but the HOWTO isn't a policy document. Something being written there doesn't make it a 'rule'.

note that taskotron should have a better depcheck implementation which may be reliable enough to be enforceable. I don't know that for sure, though, we would have to check with tflink. Still, let's say we have a perfect depcheck test and we make it 'enforcing'. OK.

What should the little note that says 'your update has been rejected' say? Well, shouldn't it point out to the policy document stating that updates have to be dependency-consistent in this way? Which would mean...we'd need to have one.

Replying to [comment:6 adamwill]:

Having said that:

"I'm looking for something we can concretely implement and enforce here. Otherwise we're just talking about stuff people should already be doing and writing it on a wiki page."

writing it on a wiki page is exactly what I want us to do. How are people to know they 'should already be doing' something if we don't write it down in the Updates Policy, which is the document that defines what people 'should be doing' in updates?

Writing it in the HOWTO is fine, but the HOWTO isn't a policy document. Something being written there doesn't make it a 'rule'.

OK. Note I did say "at the same time" in my above comment. I'm not against writing a policy page. I'm against writing one and then assuming that is enough. We need enforcement to whatever degree possible for this to work.

(I'd point out that this all seems like common sense to me, but you know what they say about common sense.)

I welcome the idea to add the section into Updates Policy. Yes, it is something everyone should be already doing, but as said, if it is not written in the policy, how can people know. Especially new Fedora contributors. The "where to seek help" paragraph has been added as I can see.

Looks good and helpful from my point of view. Thank you Adam!

Adding meeting keyword here.

At todays meeting we wanted Adamw to make his changes to the policy, but wanted to hold off enforcing it until we have more data.

Submitting multiple packages in a single Bodhi update requires maintainership of all of those packages. We should amend the policy with a mechanism for contacting a provenpackager to submit the update when appropriate.

Login to comment on this ticket.

Metadata