Hi all!
For those of you that are not on fedora-advisory-board find attached a discussion with Michael Schwendt on that list that IMHO falls in the area of the Packaging Committee. Could you guys please handle that? tia!
If the Committee thinks some parts of this discussion is the area of the FESCo please notify me or that the PC members that are part of FESCo bring it over to FESCo. Also please try to get Michael involved into this discussion -- he seems to be interested in this so he's probably one of the best people to find a solution for the issue.
But I don't think there is anything to do for FESCo *before* there are general packaging rules in the guidelines that clarify when Conflicts are allowed/acceptable and when not (for both Core and Extras). Further: Extras is no second class citizen -- if Core packages are allowed to conflict with other parts of Core then Extras packages should IMHO be allowed to Conflict with packages of Core, too. Sure, that should be controlled and I think FESCo in the future should approve each Conflict before it hits the repo. And we should check the exiositing conflicts -- but we need some guidelines from the PC first when conflicts are acceptable and when not.
CU thl
On Mon, Nov 13, 2006 at 07:08:36AM +0100, Thorsten Leemhuis wrote:
For those of you that are not on fedora-advisory-board find attached a discussion with Michael Schwendt on that list that IMHO falls in the area of the Packaging Committee. Could you guys please handle that? tia!
But I don't think there is anything to do for FESCo *before* there are general packaging rules in the guidelines that clarify when Conflicts are allowed/acceptable and when not (for both Core and Extras).
I think this is wrong (not the contents, but the responsibilities).
There is no real charter or manifesto of this group and there are often topics brought up that are questionable on whether this group should be able to decide on it. But I think the implied work is on "how, not why/what" to package. E.g. methology vs policies.
It is FC and fesco and any higher boards that setup policies and some of them are even holy grails like conflicts/replacements/overrides between FC and FE. We can't solve such a dispute, we can only implement the boards' decisions.
In short: You're god, and we're the apostels writing down your will, but you must first make up your will within the divine trinity or any other god model ;)
Axel Thimm schrieb:
On Mon, Nov 13, 2006 at 07:08:36AM +0100, Thorsten Leemhuis wrote:
For those of you that are not on fedora-advisory-board find attached a discussion with Michael Schwendt on that list that IMHO falls in the area of the Packaging Committee. Could you guys please handle that? tia!
But I don't think there is anything to do for FESCo *before* there are general packaging rules in the guidelines that clarify when Conflicts are allowed/acceptable and when not (for both Core and Extras).
I think this is wrong (not the contents, but the responsibilities).
There is no real charter or manifesto of this group and there are often topics brought up that are questionable on whether this group should be able to decide on it. But I think the implied work is on "how, not why/what" to package. E.g. methology vs policies.
Sure, policies like "Extras does not replace packages from Core" or "Extras packages don't conflict with Core" are FESCo business. But is a
Conflicts: kernel < 2.6.16
a conflict with Core or is that an acceptable way in Core and Extras to say "if you have a kernel it needs to be at least 2.6.16"? That's clearly packaging afaics.
CU thl
On Mon, 13 Nov 2006 07:08:36 +0100, Thorsten Leemhuis wrote:
For those of you that are not on fedora-advisory-board find attached a discussion with Michael Schwendt on that list that IMHO falls in the area of the Packaging Committee. Could you guys please handle that? tia!
If the Committee thinks some parts of this discussion is the area of the FESCo please notify me or that the PC members that are part of FESCo bring it over to FESCo. Also please try to get Michael involved into this discussion -- he seems to be interested in this so he's probably one of the best people to find a solution for the issue.
But I don't think there is anything to do for FESCo *before* there are general packaging rules in the guidelines that clarify when Conflicts are allowed/acceptable and when not (for both Core and Extras). Further: Extras is no second class citizen -- if Core packages are allowed to conflict with other parts of Core then Extras packages should IMHO be allowed to Conflict with packages of Core, too. Sure, that should be controlled and I think FESCo in the future should approve each Conflict before it hits the repo.
If you had added these extra paragraphs to the original thread on f-a-b list, I would have commented it with:
"Why can't FESCO simply decide whether they want Fedora Extras to be free of package conflicts or not?"
Or rephrased:
"Does FESCO want a full install of Fedora Extras and Core to be possible or not?"
About the thing referring to me, I don't like discussions that don't move anything forward. So, let me add a few more comments to make my view clear, hopefully:
At fedora.us we have had the bad habit of "abusing" clean-chroot-builds done with mach for the possibility to have conflicting -devel packages, e.g. for an old ABI and a new API of the same thing, never installed in the same buildroot at once. Occasionally, it had been referred to as "lazy packaging", to get something done (i.e. provide working and conflict-free binary rpms) instead of spending extra efforts on preparing conflict-free -devel packages just for an old API to possibly be obsolete an unknown number of weeks later.
Only a very few (2-3?) such packages are still in Fedora Extras.
Long ago, for Fedora Extras, I believe we've agreed that Fedora Extras shall be free of package conflicts. But this has never found its way onto any policy page. You know what it's like with obvious stuff that is considered common sense, it is hard to find somebody who spends time on documenting it somewhere. So, A) package contributors don't know about such a policy in case it still exists, B) Fedora Alternatives has been killed early, and C) there *are* explicit package conflicts in Extras, at least between Extras packages, and D) there are additional superfluous, dangerous, and questionable conflicts in packages (sometimes probably just old cruft, however).
The important question is at the top of my reply, though.
Beyond that, it can be decided whether packagers must add comments to every "Conflicts" tag (and not just Conflicts, but also Obsoletes), giving a proper justification.
Michael Schwendt schrieb:
On Mon, 13 Nov 2006 07:08:36 +0100, Thorsten Leemhuis wrote:
For those of you that are not on fedora-advisory-board find attached a discussion with Michael Schwendt on that list that IMHO falls in the area of the Packaging Committee. Could you guys please handle that? tia!
If the Committee thinks some parts of this discussion is the area of the FESCo please notify me or that the PC members that are part of FESCo bring it over to FESCo. Also please try to get Michael involved into this discussion -- he seems to be interested in this so he's probably one of the best people to find a solution for the issue.
But I don't think there is anything to do for FESCo *before* there are general packaging rules in the guidelines that clarify when Conflicts are allowed/acceptable and when not (for both Core and Extras). Further: Extras is no second class citizen -- if Core packages are allowed to conflict with other parts of Core then Extras packages should IMHO be allowed to Conflict with packages of Core, too. Sure, that should be controlled and I think FESCo in the future should approve each Conflict before it hits the repo.
If you had added these extra paragraphs to the original thread on f-a-b list, I would have commented it with: "Why can't FESCO simply decide whether they want Fedora Extras to be free of package conflicts or not?"
We *should* not "simply decide" without evaluating first if there are valid reasons for conflicts. All we have until now is this discussion -- we don't have rules or guidelines when conflicts are acceptable and when not.
And I don't see any reasons why those rules or guidelines need to be different between Core and Extras, and thus it's IMHO business for the packaging committee. If Spot/the Committee clearly says "No, that's not our area of work" then I'll consider it a task for FESCo again.
Or rephrased: "Does FESCO want a full install of Fedora Extras and Core to be possible or not?"
Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras.
[...]
Beyond that, it can be decided whether packagers must add comments to every "Conflicts" tag (and not just Conflicts, but also Obsoletes), giving a proper justification.
+1
CU thl
On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote:
Michael Schwendt schrieb:
On Mon, 13 Nov 2006 07:08:36 +0100, Thorsten Leemhuis wrote:
For those of you that are not on fedora-advisory-board find attached a discussion with Michael Schwendt on that list that IMHO falls in the area of the Packaging Committee. Could you guys please handle that? tia!
If the Committee thinks some parts of this discussion is the area of the FESCo please notify me or that the PC members that are part of FESCo bring it over to FESCo. Also please try to get Michael involved into this discussion -- he seems to be interested in this so he's probably one of the best people to find a solution for the issue.
But I don't think there is anything to do for FESCo *before* there are general packaging rules in the guidelines that clarify when Conflicts are allowed/acceptable and when not (for both Core and Extras). Further: Extras is no second class citizen -- if Core packages are allowed to conflict with other parts of Core then Extras packages should IMHO be allowed to Conflict with packages of Core, too. Sure, that should be controlled and I think FESCo in the future should approve each Conflict before it hits the repo.
If you had added these extra paragraphs to the original thread on f-a-b list, I would have commented it with: "Why can't FESCO simply decide whether they want Fedora Extras to be free of package conflicts or not?"
We *should* not "simply decide" without evaluating first if there are valid reasons for conflicts.
No, such "evaluation" is off-topic for this list. You're trying to complicate matters.
Perhaps based on a misunderstanding of what types of conflicts are "in the wild". For a moment, just forget your corner-cases I've commented on before.
All we have until now is this discussion -- we don't have rules or guidelines when conflicts are acceptable and when not.
And I don't see any reasons why those rules or guidelines need to be different between Core and Extras, and thus it's IMHO business for the packaging committee. If Spot/the Committee clearly says "No, that's not our area of work" then I'll consider it a task for FESCo again.
Or rephrased: "Does FESCO want a full install of Fedora Extras and Core to be possible or not?"
Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras.
Is that true?
The stuff I'm interested in first is "Conflicts: foo" which actually prevent multiple packages to be installed at once. Such conflicts do exist in Fedora Extras and asks for steering.
A simple decision without any need to argue about it.
Michael Schwendt schrieb:
On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote:
Michael Schwendt schrieb:
Or rephrased: "Does FESCO want a full install of Fedora Extras and Core to be possible or not?"
Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras.
Is that true?
I did a quick recheck, could not find any, sorry, seems I was wrong on that.
The stuff I'm interested in first is "Conflicts: foo" which actually prevent multiple packages to be installed at once. Such conflicts do exist in Fedora Extras and asks for steering.
I'm all for that rule -- but for *both Core and Extras* and thus from the packaging committee. E.g. something like this:
"Packages should not explicitly conflict with other packages that are part of the same release of Fedora Core or Extras."
And I'd like to see some guidelines from the packaging committee in what situations it's okay to use the Conflicts tag for other purposes (e.g. Conflicts: kernel < 2.6.16).
CU thl
"TL" == Thorsten Leemhuis fedora@leemhuis.info writes:
TL> "Packages should not explicitly conflict with other packages that TL> are part of the same release of Fedora Core or Extras."
I still contend that such a statement needs to come from FESCo or the FAB (perhaps working together), not the packaging committee. It's purely a policy decision not relating to the form of packages.
TL> And I'd like to see some guidelines from the packaging committee TL> in what situations it's okay to use the Conflicts tag for other TL> purposes (e.g. Conflicts: kernel < 2.6.16).
That is reasonable. Perhaps we can brainstorm a bit at our meeting today and get a volunteer to write up a proposal.
- J<
Le mardi 14 novembre 2006 à 12:52 +0100, Michael Schwendt a écrit :
On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote:
Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras.
Is that true?
The kernel package, for example, has a boatload of versionned conflicts to prevent installation on a system with the wrong userspace level.
On Tue, 14 Nov 2006 19:01:01 +0100, Nicolas Mailhot wrote:
Le mardi 14 novembre 2006 à 12:52 +0100, Michael Schwendt a écrit :
On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote:
Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras.
Is that true?
The kernel package, for example, has a boatload of versionned conflicts to prevent installation on a system with the wrong userspace level.
Void.
The right userspace tools are part of Core, so these conditional conflicts only become active under corner-case conditions and then create artificial hurdles.
Michael Schwendt wrote:
On Tue, 14 Nov 2006 19:01:01 +0100, Nicolas Mailhot wrote:
Le mardi 14 novembre 2006 à 12:52 +0100, Michael Schwendt a écrit :
On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote:
Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras.
Is that true?
The kernel package, for example, has a boatload of versionned conflicts to prevent installation on a system with the wrong userspace level.
Void.
The right userspace tools are part of Core, so these conditional conflicts only become active under corner-case conditions and then create artificial hurdles.
There have been times in the past where I wanted to try a rawhide kernel on a current-release Fedora version to see if it fixed an issue I was having. The versioned requires/conflicts that the kernel has were very useful at that time, as it told me what else I needed to pull from rawhide to do the experiment.
Paul.
On Tue, 14 Nov 2006 18:40:45 +0000, Paul Howarth wrote:
Michael Schwendt wrote:
On Tue, 14 Nov 2006 19:01:01 +0100, Nicolas Mailhot wrote:
Le mardi 14 novembre 2006 à 12:52 +0100, Michael Schwendt a écrit :
On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote:
Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras.
Is that true?
The kernel package, for example, has a boatload of versionned conflicts to prevent installation on a system with the wrong userspace level.
Void.
The right userspace tools are part of Core, so these conditional conflicts only become active under corner-case conditions and then create artificial hurdles.
There have been times in the past where I wanted to try a rawhide kernel on a current-release Fedora version to see if it fixed an issue I was having. The versioned requires/conflicts that the kernel has were very useful at that time, as it told me what else I needed to pull from rawhide to do the experiment.
No.
Read your own paragraph once more. You write "requires/conflicts" and mix _two_ things.
The versioned "Requires" were "very useful", because they told you what you needed, and you then fetched sufficient upgrades. On the contrary, "Conflicts" don't tell you the way out.
Le mardi 14 novembre 2006 à 20:14 +0100, Michael Schwendt a écrit :
The versioned "Requires" were "very useful", because they told you what you needed, and you then fetched sufficient upgrades. On the contrary, "Conflicts" don't tell you the way out.
Conflicts : - save your ass before you hose your system with an unsupported combination - don't force you to have half the distro as installed requires just to be sure there's no version conflict - tell you A won't work with B (version). So the obvious way out is : a. install a compatible b version b. remove B if you don't really need it
Nicolas Mailhot (nicolas.mailhot@laposte.net) said:
Conflicts :
- save your ass before you hose your system with an unsupported
combination
- don't force you to have half the distro as installed requires just to
be sure there's no version conflict
- tell you A won't work with B (version). So the obvious way out is : a.
install a compatible b version b. remove B if you don't really need it
Exactly. The kernel doesn't *require* that you have oprofile installed, but it may not work with a sufficiently old oprofile.
Bill
On Tue, 14 Nov 2006 14:29:01 -0500, Bill Nottingham wrote:
Nicolas Mailhot said:
Conflicts :
- save your ass before you hose your system with an unsupported
combination
- don't force you to have half the distro as installed requires just to
be sure there's no version conflict
- tell you A won't work with B (version). So the obvious way out is : a.
install a compatible b version b. remove B if you don't really need it
Exactly. The kernel doesn't *require* that you have oprofile installed, but it may not work with a sufficiently old oprofile.
That's why a sufficiently new oprofile is provided together with the kernel in the same distribution.
Only if you leave this package universe and want to use a kernel or oprofile from elsewhere, introducing such versioned conflicts may be justified. And hopefully they are well-maintained.
But still, it only relocates a packaging problem from build-time to install-time. It would be much better, if compatibility were checked at build-time --> refuse to build when something in the distribution is insufficient. And if it's a fully optional package and smart, it would examine the system for compatibility at run-time.
Anyway, just that it's not forgotten. There are non-versioned conflicts in Extras, and those are of primary interest.
On Tue, 2006-11-14 at 19:32 +0100, Michael Schwendt wrote:
On Tue, 14 Nov 2006 19:01:01 +0100, Nicolas Mailhot wrote:
Le mardi 14 novembre 2006 à 12:52 +0100, Michael Schwendt a écrit :
On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote:
Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras.
Is that true?
The kernel package, for example, has a boatload of versionned conflicts to prevent installation on a system with the wrong userspace level.
Void.
The right userspace tools are part of Core, so these conditional conflicts only become active under corner-case conditions and then create artificial hurdles.
== bug
Frankly speaking, I am having difficulties to imagine valid reasons when an explicit "Conflicts:" in an rpm.spec makes any sense, and am inclined to think all such explicit "Conflicts:" actually are packaging bugs.
Am I missing something?
Ralf
packaging@lists.fedoraproject.org
-
Axel Thimm -
Bill Nottingham -
Jason L Tibbitts III -
Michael Schwendt -
Nicolas Mailhot -
Paul Howarth -
Ralf Corsepius -
Thorsten Leemhuis