I drafted a proposal for when it is ok to use Conflicts: (almost never):
http://fedoraproject.org/wiki/PackagingDrafts/Conflicts
Keep in mind that while it is not stated in the Draft, the kernel is considered a special case, and I feel strongly that most (if not all) of its existing Conflicts: will be approved.
Fedora Packaging Committee Members should vote via email on this issue, as we did not have quorum in the IRC meeting to vote.
~spot
Tom 'spot' Callaway (tcallawa@redhat.com) said:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
http://fedoraproject.org/wiki/PackagingDrafts/Conflicts
Keep in mind that while it is not stated in the Draft, the kernel is considered a special case, and I feel strongly that most (if not all) of its existing Conflicts: will be approved.
Fedora Packaging Committee Members should vote via email on this issue, as we did not have quorum in the IRC meeting to vote.
Example: My package, foo-game doesn't work when bar is older than 1.2.3. WRONG: Conflicts: bar < 1.2.3 RIGHT: Requires: bar >= 1.2.3
What about when foo-game doesn't actually require bar?
To be more precise:
$ rpm -q --conflicts initscripts mkinitrd < 4.0 kernel < 2.6.12 ypbind < 1.6-12 psacct < 6.3.2-12 kbd < 1.06-19 lokkit < 0.50-14 dhclient < 3.0.3-7 tcsh < 6.13-5 xorg-x11 glib2 < 2.11.1-2
Some of these can be flipped to requires (kernel, for example, glib2). However, making initscripts *require* things like ypbind, psacct, dhclient would be wrong.
Bill
Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
http://fedoraproject.org/wiki/PackagingDrafts/Conflicts
Keep in mind that while it is not stated in the Draft, the kernel is considered a special case, and I feel strongly that most (if not all) of its existing Conflicts: will be approved.
Fedora Packaging Committee Members should vote via email on this issue, as we did not have quorum in the IRC meeting to vote.
Example: My package, foo-game doesn't work when bar is older than 1.2.3. WRONG: Conflicts: bar < 1.2.3 RIGHT: Requires: bar >= 1.2.3
What about when foo-game doesn't actually require bar?
To be more precise:
$ rpm -q --conflicts initscripts mkinitrd < 4.0 kernel < 2.6.12 ypbind < 1.6-12 psacct < 6.3.2-12 kbd < 1.06-19 lokkit < 0.50-14 dhclient < 3.0.3-7 tcsh < 6.13-5 xorg-x11 glib2 < 2.11.1-2
Some of these can be flipped to requires (kernel, for example, glib2). However, making initscripts *require* things like ypbind, psacct, dhclient would be wrong.
Already covered =>
When you must use Conflicts
If you find yourself in a situation where ... this package cannot function when another package is installed ... you need to ...
Paul.
On Tue, Dec 05, 2006 at 05:37:42PM +0000, Paul Howarth wrote:
Already covered =>
When you must use Conflicts
If you find yourself in a situation where ... this package cannot function when another package is installed ... you need to ...
Maybe an example could help make things clearer here?
-- Pat
$ rpm -q --conflicts initscripts mkinitrd < 4.0 kernel < 2.6.12 ypbind < 1.6-12 psacct < 6.3.2-12 kbd < 1.06-19 lokkit < 0.50-14 dhclient < 3.0.3-7 tcsh < 6.13-5 xorg-x11 glib2 < 2.11.1-2
Some of these can be flipped to requires (kernel, for example, glib2). However, making initscripts *require* things like ypbind, psacct, dhclient would be wrong.
And in those cases, you should use Conflicts, you just need to provide rationalization to the appropriate Fedora Committee and have a comment:
e.g.
# When ypbind is older than 1.6-12, the initscripts explode horribly. # ypbind is not required for initscripts to function. Conflicts: ypbind < 1.6-12
~spot
On Tue, 2006-12-05 at 11:40 -0600, Tom 'spot' Callaway wrote:
$ rpm -q --conflicts initscripts mkinitrd < 4.0 kernel < 2.6.12 ypbind < 1.6-12 psacct < 6.3.2-12 kbd < 1.06-19 lokkit < 0.50-14 dhclient < 3.0.3-7 tcsh < 6.13-5 xorg-x11 glib2 < 2.11.1-2
Some of these can be flipped to requires (kernel, for example, glib2). However, making initscripts *require* things like ypbind, psacct, dhclient would be wrong.
And in those cases, you should use Conflicts, you just need to provide rationalization to the appropriate Fedora Committee and have a comment:
e.g.
# When ypbind is older than 1.6-12, the initscripts explode horribly. # ypbind is not required for initscripts to function. Conflicts: ypbind < 1.6-12
+1 to defining what's inappropriate for Conflicts and how to work around things.
+1 for commenting anytime Conflicts is used.
-1 to ask the Steering Committee to audit these on a case by case basis. Conflicts should be infrequently used, but it's not really something that I think needs to be evaluated like that. It's not political and it's not really an abuse of a tag when used correctly. It's a technical decision and should be worked out by a reviewer and packager. (And "after importation QA" if we had that.)
Maybe making it clearer when it's okay to use Conflicts would be a good idea if we do that though:
""" The only time Conflicts are allowed is when a package does not Require the other package but can make use of it as long as the other package is of the correct version. When this occurs you are allowed to use a versioned Conflicts to specify this and you must also include a comment which explains the reasoning:
# When ypbind is older than 1.6-12, the initscripts explode horribly. # ypbind is not required for initscripts to function. Conflicts: ypbind < 1.6-12
If there is another instance where you think a Conflicts is required, please ask for input from the Packaging Committee so they can discuss it and decide if a change is needed to these Guidelines. """
-Toshio
On Tue, 2006-12-05 at 13:18 -0800, Toshio Kuratomi wrote:
-1 to ask the Steering Committee to audit these on a case by case basis. Conflicts should be infrequently used, but it's not really something that I think needs to be evaluated like that. It's not political and it's not really an abuse of a tag when used correctly. It's a technical decision and should be worked out by a reviewer and packager. (And "after importation QA" if we had that.)
I had the same hesitation initially - if this is somethign that comes upa lot or slows down reviews, we/FESCo will need to come with a more lightweight way. Though I wouldn't just leave conflicts up to individual reviewers, since they can have bad implications on the useability of the distro as a whole; that's where conflicts deserve more attention than requires (too many requires bloat installs, but don't keep you from using things in parallel).
David
On Tue, Dec 05, 2006 at 10:04:39PM +0000, David Lutterkort wrote:
On Tue, 2006-12-05 at 13:18 -0800, Toshio Kuratomi wrote:
I had the same hesitation initially - if this is somethign that comes upa lot or slows down reviews, we/FESCo will need to come with a more lightweight way. Though I wouldn't just leave conflicts up to individual reviewers, since they can have bad implications on the useability of the distro as a whole; that's where conflicts deserve more attention than requires (too many requires bloat installs, but don't keep you from using things in parallel).
Many other things can affect the distro as a whole (Provides, for example) but that doesn't mean that FESCO should look over the issue. I am not in the packaging commitee, but I think that conflicts are not unlike other packaging issues and I fail to see why FESCO should be asked for that issue. Having the conflict guidelines in the packaging guidelines (with an example of a case where conflicts is usefull) should be enough in my opinion. And in case of doubt, it seems to me that it is better to ask to the mailing list than too annoy FESCO.
-- Pat
Tom 'spot' Callaway wrote:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
...
Fedora Packaging Committee Members should vote via email on this issue,
Looks sane, +1.
-- Rex
On Tue, Dec 05, 2006 at 11:43:59AM -0600, Rex Dieter wrote:
Tom 'spot' Callaway wrote:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
...
Fedora Packaging Committee Members should vote via email on this issue,
Looks sane, +1.
+1
On Tue, 2006-12-05 at 11:43 -0600, Rex Dieter wrote:
Tom 'spot' Callaway wrote:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
...
Fedora Packaging Committee Members should vote via email on this issue,
Looks sane, +1.
Agreed, +1
David
tcallawa@redhat.com ("Tom 'spot' Callaway") writes:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
The statement
| My package, foo-game doesn't work when bar is older than 1.2.3. | WRONG: Conflicts: bar < 1.2.3 | RIGHT: Requires: bar >= 1.2.3
is wrong and should be the opposite. There should not be added a Requires: when package 'foo' works without 'bar' but fails with 'bar < 1.2.3'.
Popular example is the 'kernel' package. Lot of packages won't work with kernel 2.4 but it would be wrong to Require: the 'kernel' package.
Enrico
On Tue, 2006-12-05 at 19:50 +0100, Enrico Scholz wrote:
tcallawa@redhat.com ("Tom 'spot' Callaway") writes:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
The statement
| My package, foo-game doesn't work when bar is older than 1.2.3. | WRONG: Conflicts: bar < 1.2.3 | RIGHT: Requires: bar >= 1.2.3
is wrong and should be the opposite. There should not be added a Requires: when package 'foo' works without 'bar' but fails with 'bar < 1.2.3'.
The example is poor in that aspect. If you assume that foo-game needs bar, but will not work with older versions of bar (this is the normal case), then the example holds. I'll update the wording to reflect this.
~spot
Le mardi 05 décembre 2006 à 13:22 -0600, Tom 'spot' Callaway a écrit :
The example is poor in that aspect. If you assume that foo-game needs bar, but will not work with older versions of bar (this is the normal case), then the example holds. I'll update the wording to reflect this.
Please also make sure your proposal covers the case explained there : http://www.redhat.com/archives/fedora-packaging/2006-November/msg00026.html
Regards,
On Tue, 2006-12-05 at 20:55 +0100, Nicolas Mailhot wrote:
Le mardi 05 décembre 2006 à 13:22 -0600, Tom 'spot' Callaway a écrit :
The example is poor in that aspect. If you assume that foo-game needs bar, but will not work with older versions of bar (this is the normal case), then the example holds. I'll update the wording to reflect this.
Please also make sure your proposal covers the case explained there : http://www.redhat.com/archives/fedora-packaging/2006-November/msg00026.html
I think the rationale presented there for Conflicts use is OK.
Again, the policy is "No use of Conflicts: without good reason". If you have a good reason, we'll approve it, you document it in the spec, and we all move on. :)
~spot
Le mardi 05 décembre 2006 à 14:02 -0600, Tom 'spot' Callaway a écrit :
On Tue, 2006-12-05 at 20:55 +0100, Nicolas Mailhot wrote:
Le mardi 05 décembre 2006 à 13:22 -0600, Tom 'spot' Callaway a écrit :
The example is poor in that aspect. If you assume that foo-game needs bar, but will not work with older versions of bar (this is the normal case), then the example holds. I'll update the wording to reflect this.
Please also make sure your proposal covers the case explained there : http://www.redhat.com/archives/fedora-packaging/2006-November/msg00026.html
I think the rationale presented there for Conflicts use is OK.
Again, the policy is "No use of Conflicts: without good reason". If you have a good reason, we'll approve it, you document it in the spec, and we all move on. :)
Operation "have spot document my conflict on his wiki page" failed
Damn :)
On Tue, 05 Dec 2006 19:50:12 +0100, Enrico Scholz wrote:
"Tom 'spot' Callaway" writes:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
The statement
| My package, foo-game doesn't work when bar is older than 1.2.3. | WRONG: Conflicts: bar < 1.2.3 | RIGHT: Requires: bar >= 1.2.3
is wrong and should be the opposite. There should not be added a Requires: when package 'foo' works without 'bar' but fails with 'bar < 1.2.3'.
Popular example is the 'kernel' package. Lot of packages won't work with kernel 2.4 but it would be wrong to Require: the 'kernel' package.
What does Anaconda do during a dist upgrade in that case?
bugs.michael@gmx.net (Michael Schwendt) writes:
Popular example is the 'kernel' package. Lot of packages won't work with kernel 2.4 but it would be wrong to Require: the 'kernel' package.
What does Anaconda do during a dist upgrade in that case?
dunno; correct thing would be to abort the transaction or ask the user whether he wants to remove the old kernel during the transaction.
Enrico
On Tue, 2006-12-05 at 11:26 -0600, Tom 'spot' Callaway wrote:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
+1, except one detail:
There are many types of files which can conflict between multiple packages. Instead of using Conflicts:, try the following:
- man page name conflicts: Rename the man pages to include a prefix of
the providing package (e.g. foo-check.1.gz vs check.1.gz)
IMO, this example is bogus: Man-pages should always be named after what they are trying to document, i.e. section 1 mans must be named after the application.
=> Documenting /usr/bin/check in a man-page named foo-check.1 because it conflicts with /bin/check's man-page is a no-go.
Better, change the man-pages suffix, or change the name of the application and the name of man-page at the same time.
Ralf
On 12/5/06, Ralf Corsepius rc040203@freenet.de wrote:
On Tue, 2006-12-05 at 11:26 -0600, Tom 'spot' Callaway wrote:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
+1, except one detail:
There are many types of files which can conflict between multiple packages. Instead of using Conflicts:, try the following:
- man page name conflicts: Rename the man pages to include a prefix of
the providing package (e.g. foo-check.1.gz vs check.1.gz)
IMO, this example is bogus: Man-pages should always be named after what they are trying to document, i.e. section 1 mans must be named after the application.
=> Documenting /usr/bin/check in a man-page named foo-check.1 because it conflicts with /bin/check's man-page is a no-go.
Better, change the man-pages suffix, or change the name of the application and the name of man-page at the same time.
Perhaps a better example would be a .3 man page such as:
man3/foo.3.gz vs. man3/bar::foo.3.gz
-Chris
On Wed, 2006-12-06 at 05:37 -0800, Christopher Stone wrote:
On 12/5/06, Ralf Corsepius rc040203@freenet.de wrote:
On Tue, 2006-12-05 at 11:26 -0600, Tom 'spot' Callaway wrote:
I drafted a proposal for when it is ok to use Conflicts: (almost never):
+1, except one detail:
There are many types of files which can conflict between multiple packages. Instead of using Conflicts:, try the following:
- man page name conflicts: Rename the man pages to include a prefix of
the providing package (e.g. foo-check.1.gz vs check.1.gz)
IMO, this example is bogus: Man-pages should always be named after what they are trying to document, i.e. section 1 mans must be named after the application.
=> Documenting /usr/bin/check in a man-page named foo-check.1 because it conflicts with /bin/check's man-page is a no-go.
Better, change the man-pages suffix, or change the name of the application and the name of man-page at the same time.
Perhaps a better example would be a .3 man page such as:
man3/foo.3.gz vs. man3/bar::foo.3.gz
Much easier, simply append something to the man suffix:
man1/check.1foo.gz
It's the traditional way many *nixes circumvented this problem.
For a real world example in FE cf. Coin2 and Inventor (Both implement the same API and therefore naturally must conflict).
Ralf
On Tue, 2006-12-05 at 11:26 -0600, Tom 'spot' Callaway wrote:
"library name conflicts: Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file."
The ld.so.conf part does not sound good to me. While it would avoid the low level conflict, doesn't adding the new subdir to ld.so.conf mean that we now have two different libs with the same name in the linker's default path - which one to load in which situations? I suppose instead of global ld.so.conf, RPATH in apps that require the subdir'd lib would be a better solution, but hopefully someone can point out an even better one?
"TC" == Tom 'spot' Callaway tcallawa@redhat.com writes:
TC> I drafted a proposal for when it is ok to use Conflicts: (almost TC> never): http://fedoraproject.org/wiki/PackagingDrafts/Conflicts
I just wanted to remind folks that FESCo would really like for us to finish up guidelines for conflicts (and Conflicts:) soon. Not much has happened to the draft since it was presented.
The discussion I actually recall revolved around the suggestions in the "Conflicting Files" section:
man pages should probably go into different "sections" (like Coin2-devel and Inventor-devel) instead of being renamed.
I recall objection to using "alternatives" for conflicting binaries.
There's probably plenty I don't recall, however. We really should try to finish this up and present it to the various committees next week.
- J<
On Wednesday 10 January 2007 16:35, Jason L Tibbitts III wrote:
I just wanted to remind folks that FESCo would really like for us to finish up guidelines for conflicts (and Conflicts:) soon. Not much has happened to the draft since it was presented.
The discussion I actually recall revolved around the suggestions in the "Conflicting Files" section:
man pages should probably go into different "sections" (like Coin2-devel and Inventor-devel) instead of being renamed.
I recall objection to using "alternatives" for conflicting binaries.
There's probably plenty I don't recall, however. We really should try to finish this up and present it to the various committees next week.
What about the situation where Foo conflicts with bar <= 1.0, but Foo doesn't require bar to run? A Requires: bar > 1.0 doesn't work here, can a conflicts be used in this case? Is this an acceptable situation for the list at the bottom of the page?
On Wednesday 10 January 2007 16:53, Jesse Keating wrote:
On Wednesday 10 January 2007 16:35, Jason L Tibbitts III wrote:
I just wanted to remind folks that FESCo would really like for us to finish up guidelines for conflicts (and Conflicts:) soon. Not much has happened to the draft since it was presented.
The discussion I actually recall revolved around the suggestions in the "Conflicting Files" section:
man pages should probably go into different "sections" (like Coin2-devel and Inventor-devel) instead of being renamed.
I recall objection to using "alternatives" for conflicting binaries.
There's probably plenty I don't recall, however. We really should try to finish this up and present it to the various committees next week.
What about the situation where Foo conflicts with bar <= 1.0, but Foo doesn't require bar to run? A Requires: bar > 1.0 doesn't work here, can a conflicts be used in this case? Is this an acceptable situation for the list at the bottom of the page?
Also, this draft seems to be missing a clear "Problem this is trying to solve" statement, which goes a long way to getting people to understand/comment on it.
On Wed, 10 Jan 2007 16:53:41 -0500, Jesse Keating wrote:
What about the situation where Foo conflicts with bar <= 1.0, but Foo doesn't require bar to run? A Requires: bar > 1.0 doesn't work here, can a conflicts be used in this case? Is this an acceptable situation for the list at the bottom of the page?
It depends on two questions:
Does the distribution release include a conflicting pair of foo and bar?
If after a fresh install, foo and bar are not installed. Does a "yum install foo bar" work? (In your example. is bar <= 1.0?)
Is there an upgrade path for either one?
That means the conflict must not make an upgrade from a previous dist release impossible. As in telling the user that there is a conflict, and when the user tries to exclude one of the packages, it is pulled back in by the dependency chain and leads to a "WTF?" scenario. E.g. installed is foo, and the dist upgrade wants to update foo + install a conflicting version of bar, or vice versa.
Jesse Keating (jkeating@redhat.com) said:
What about the situation where Foo conflicts with bar <= 1.0, but Foo doesn't require bar to run? A Requires: bar > 1.0 doesn't work here, can a conflicts be used in this case? Is this an acceptable situation for the list at the bottom of the page?
So, my usual pile of examples would be:
kernel: Conflicts: ipw2200-firmware < 2.4
i.e., if you're using this kernel with ipw2200, you need at least that level of firmware.
initscripts: Conflicts: xorg-x11 (essentially, with xorg-not-in-/usr Conflicts: kernel < 2.6.12 (requires at least that new of a kernel)
and so on.
Bill
packaging@lists.fedoraproject.org