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
--- Begin Message ---
On Sat, 11 Nov 2006 14:49:16 +0100, Thorsten Leemhuis wrote:
> Thus I'm more and more
> wondering if we we should re-evaluate the "Fedora Alternatives" idea
> that got buried. Users of stable releases that want a bit more up2date
> stuff could get in there, while users that are a careful stick to the
> main distro, and users that like some risks use devel.
>
> But we have some much on our plate currently, thus I don't think it'll
> be wise to discuss that now.
So?
Rest assured, it would be wise. Much wiser than the current crap in FE,
where we have packages which conflict with other packages in Core or
Extras _explicitly_.
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
On Sat, 2006-11-11 at 16:48 +0100, Michael Schwendt wrote:
> On Sat, 11 Nov 2006 14:49:16 +0100, Thorsten Leemhuis wrote:
>
> > Thus I'm more and more
> > wondering if we we should re-evaluate the "Fedora Alternatives" idea
> > that got buried. Users of stable releases that want a bit more up2date
> > stuff could get in there, while users that are a careful stick to the
> > main distro, and users that like some risks use devel.
> >
> > But we have some much on our plate currently, thus I don't think it'll
> > be wise to discuss that now.
>
> So?
>
> Rest assured, it would be wise. Much wiser than the current crap in FE,
> where we have packages which conflict with other packages in Core or
> Extras _explicitly_.
>
FE has packages explicitly conflicting with pkgs in core? I thought that
was against the rules?
-sv
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
On Sat, 11 Nov 2006 12:37:03 -0500, seth vidal wrote:
> On Sat, 2006-11-11 at 16:48 +0100, Michael Schwendt wrote:
> > On Sat, 11 Nov 2006 14:49:16 +0100, Thorsten Leemhuis wrote:
> >
> > > Thus I'm more and more
> > > wondering if we we should re-evaluate the "Fedora Alternatives" idea
> > > that got buried. Users of stable releases that want a bit more up2date
> > > stuff could get in there, while users that are a careful stick to the
> > > main distro, and users that like some risks use devel.
> > >
> > > But we have some much on our plate currently, thus I don't think it'll
> > > be wise to discuss that now.
> >
> > So?
> >
> > Rest assured, it would be wise. Much wiser than the current crap in FE,
> > where we have packages which conflict with other packages in Core or
> > Extras _explicitly_.
> >
>
> FE has packages explicitly conflicting with pkgs in core? I thought that
> was against the rules?
During package review that may be true. Still there are packages which
conflict with eachother explicitly, and the number of "Conflicts" tags in
Extras is increasing, too. "grep ^Confli * -R" lists 46 explicit
conflicts, among them are Core package names. Where they are versioned,
maybe they don't conflict with anything actually. The existence of such
"Conflicts" lines in spec files is dangerous and highly questionable.
Since Extras are always built only against latest updates, would you put
your hand into the fire that it is always safe to upgrade from something
like up-to-date FC(n)+Extras to CD/DVD based FC(n+1)?
Further, stuff like initng even replaces a core OS process, works with a
modified boot menu and clearly is an alternative to Core and not a clean
add-on. And it is not the only Extras package which is run at boot-time
and must not fail ever at first-boot after an upgrade.
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
On Sat, 2006-11-11 at 19:59 +0100, Michael Schwendt wrote:
> During package review that may be true. Still there are packages which
> conflict with eachother explicitly, and the number of "Conflicts" tags in
> Extras is increasing, too. "grep ^Confli * -R" lists 46 explicit
> conflicts, among them are Core package names. Where they are versioned,
> maybe they don't conflict with anything actually. The existence of such
> "Conflicts" lines in spec files is dangerous and highly questionable.
Agreed. Does fesco know about this? Is anyone looking into correcting
those?
We should be able to automatically scan for those on check in, I'd
think.
> Since Extras are always built only against latest updates, would you put
> your hand into the fire that it is always safe to upgrade from something
> like up-to-date FC(n)+Extras to CD/DVD based FC(n+1)?
I thought that was the point of evaluating pkgs.
> Further, stuff like initng even replaces a core OS process, works with a
> modified boot menu and clearly is an alternative to Core and not a clean
> add-on. And it is not the only Extras package which is run at boot-time
> and must not fail ever at first-boot after an upgrade.
it replaces only in functionality. It doesn't actually have an obsolete
and, afaik, it doesn't have any conflicting files, does it?
-sv
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
seth vidal schrieb:
> On Sat, 2006-11-11 at 19:59 +0100, Michael Schwendt wrote:
>> During package review that may be true. Still there are packages which
>> conflict with eachother explicitly, and the number of "Conflicts" tags in
>> Extras is increasing, too. "grep ^Confli * -R" lists 46 explicit
>> conflicts, among them are Core package names. Where they are versioned,
>> maybe they don't conflict with anything actually. The existence of such
>> "Conflicts" lines in spec files is dangerous and highly questionable.
> Agreed.
Well, we need some conflicts for good reasons now and then. But yes,
they should often be avoided.
I just looked at a bit closer:
Extras: 2315 spec files in devel contain 46 conflicts in total
Core: 1550 spec files in devel contain 308 conflicts in total
Wow!
> Does fesco know about this?
I'm not aware of any discussions about that in our outside of FESCo in
the past weeks.
> Is anyone looking into correcting those?
I don't think so. The questions also is: Do they need to be fixed? Some
of of those 46 look valid on a first sight.
And BTW, where is the rule in the packaging guidelines and the point in
the review guidelines that forbids "Conflicts" or encourages people to
avoid them? It must be somewhere, but it seems I'm to blind to find it
-- maybe someone from the Packaging Committee can enlighten me...
> We should be able to automatically scan for those on check in, I'd
> think.
We need to set up something that periodically scan the spec files for
common "errors", "troublemakers" or "historic cruft" (if possible).
>> Since Extras are always built only against latest updates, would you put
>> your hand into the fire that it is always safe to upgrade from something
>> like up-to-date FC(n)+Extras to CD/DVD based FC(n+1)?
> I thought that was the point of evaluating pkgs.
We have some checks that check working upgrade paths already, but a lot
of packagers of both Core and Extras seem to ignore the reports that get
send to maintainers-list. I think both Core and Extras needs one person
(the release manager?) that fixes the stuff when max three days after
the problem showed up as the maintainers seem to ignore such problems
often quite to long IMHO.
>> Further, stuff like initng even replaces a core OS process, works with a
>> modified boot menu and clearly is an alternative to Core and not a clean
>> add-on. And it is not the only Extras package which is run at boot-time
>> and must not fail ever at first-boot after an upgrade.
> it replaces only in functionality. It doesn't actually have an obsolete
> and, afaik, it doesn't have any conflicting files, does it?
I think so, otherwise it should not have passed review (but I never
looked at it).
CU
thl
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
>>>>> "TL" == Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> writes:
TL> And BTW, where is the rule in the packaging guidelines and the
TL> point in the review guidelines that forbids "Conflicts" or
TL> encourages people to avoid them?
There isn't one; Conflicts: is a perfectly valid thing to have. It's
not really the Packaging committee's business to day whether conflicts
are permitted; its up to either FESCo or the core cabal to make that
policy.
What we could do is pass a guideline that any conflicts should be explicit
through a Conflicts: header, and to require specfile comments about
the nature of the conflict. I'll raise it for discussion. Of course,
this is moot if conflicts simply aren't permitted, but I personally
don't think that's reasonable.
- J<
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
Jason L Tibbitts III schrieb:
>>>>>> "TL" == Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> writes:
> TL> And BTW, where is the rule in the packaging guidelines and the
> TL> point in the review guidelines that forbids "Conflicts" or
> TL> encourages people to avoid them?
> There isn't one; Conflicts: is a perfectly valid thing to have.
Well, sure, but the rule in the beginning always was "Extras packages
don't conflict or replace packages from Core". Well, it seems it got
lost on the way. I'm wondering if we should put it back, but I tend to
think that's worth the trouble as Core and Extras might merge by FC7 in
any case.
> It's
> not really the Packaging committee's business to day whether conflicts
> are permitted; its up to either FESCo or the core cabal to make that
> policy.
Sure, it's FESCo business to declare a rule "Extras packages don't
conflict or replace packages from Core".
But maybe we should have general rules for conflicts that are for both
Extras and Core and thus business for the Packaging Committee. Michael,
what's your opinion here?
> What we could do is pass a guideline that any conflicts should be explicit
> through a Conflicts: header, and to require specfile comments about
> the nature of the conflict. I'll raise it for discussion.
tia
> Of course,
> this is moot if conflicts simply aren't permitted, but I personally
> don't think that's reasonable.
+1
CU
thl
P.S.: Should we move this discussion to fedora-maintainers? That's would
be the better place afaics.
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
On 11/12/06, Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote:
Jason L Tibbitts III schrieb:
>>>>>> "TL" == Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> writes:
> TL> And BTW, where is the rule in the packaging guidelines and the
> TL> point in the review guidelines that forbids "Conflicts" or
> TL> encourages people to avoid them?
> There isn't one; Conflicts: is a perfectly valid thing to have.
Well, sure, but the rule in the beginning always was "Extras packages
don't conflict or replace packages from Core". Well, it seems it got
lost on the way. I'm wondering if we should put it back, but I tend to
think that's worth the trouble as Core and Extras might merge by FC7 in
any case.
I've always interperated this:
MUST: Packages must not own files or directories already owned by
other packages.
as conflicts should be avoided. I've even filed bug reports:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201279
-Mike
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
On Sun, 12 Nov 2006 17:52:57 +0100, Thorsten Leemhuis wrote:
[Conflicts]
> > Is anyone looking into correcting those?
>
> I don't think so. The questions also is: Do they need to be fixed? Some
> of of those 46 look valid on a first sight.
Did you know that in 99.9% of the cases it would be possible to replace
them with proper "Requires" or an additional "Obsoletes" in a different
package?
Explicit Conflicts are the worse opposite of versioned "Requires", because
they tell the package resolver what is forbidden, but don't tell it how to
fix it without applying lots of guessing. And if there is no way out, uhm,
that's unclean packaging and not suitable for an add-ons repository.
[...]
Example:
devel/hunky-fonts/hunky-fonts.spec
Conflicts: fontconfig < 2.3.93
There's no comment that explains this. Can we please require packagers
to explain such unusual things in the spec file?
Either it's superfluous Conflicts information (overuse of an RPM feature)
or at some point in time the package really conflicted with Core's
fontconfig. In that case, ouch.
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
Michael Schwendt schrieb:
> On Sun, 12 Nov 2006 17:52:57 +0100, Thorsten Leemhuis wrote:
> [Conflicts]
>>> Is anyone looking into correcting those?
>> I don't think so. The questions also is: Do they need to be fixed? Some
>> of of those 46 look valid on a first sight.
> Did you know that in 99.9% of the cases it would be possible to replace
> them with proper "Requires" or an additional "Obsoletes" in a different
> package?
No, I never did analysis so I don't know if it's "99,9%" or "99,8%" (or
even less).
> Explicit Conflicts are the worse opposite of versioned "Requires",
As I wrote earlier: Well, we need some conflicts for good reasons now
and then. But yes, they should often be avoided.
> because
> they tell the package resolver what is forbidden, but don't tell it how to
> fix it without applying lots of guessing. And if there is no way out, uhm,
> that's unclean packaging and not suitable for an add-ons repository.
> [...]
> Example:
> devel/hunky-fonts/hunky-fonts.spec
> Conflicts: fontconfig < 2.3.93
>
> There's no comment that explains this.
> Can we please require packagers
> to explain such unusual things in the spec file?
Talk to the packaging committee please. That really their business. I'm
all for it.
> [...]
And example for a *afaik* (and Michael, please correct me if I'm wrong)
valid conflicts (it was even discusses on fedora-devel quite some time
ago iirc):
libhugetlbfs/libhugetlbfs.spec
Conflicts: kernel < 2.6.16
The package for example works fine in a chroot (vserver anyone?) without
a kernel installed, but on normal machines the installed kernels needs
at least to be 2.6.16. And the conflicts makes sure that the users has
none installed that are older -- that's won't work with a Requires (the
user could still have old kernel around and might accidentally boot into
it).
CU
thl
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--- Begin Message ---
On Sun, 12 Nov 2006 22:09:33 +0100, Thorsten Leemhuis wrote:
> > Explicit Conflicts are the worse opposite of versioned "Requires",
>
> As I wrote earlier: Well, we need some conflicts for good reasons now
> and then.
Please enlighten me. How good can a reason be to have such a conflict?
At no point in time there must ever be a reason for an Extras package
to conflict with Core. Extras packages are made for a well-known target.
> > Example:
> > devel/hunky-fonts/hunky-fonts.spec
> > Conflicts: fontconfig < 2.3.93
> >
> > There's no comment that explains this.
> > Can we please require packagers
> > to explain such unusual things in the spec file?
>
> Talk to the packaging committee please. That really their business. I'm
> all for it.
Then simply back up the proposal and forward it appropriately as part of
FESCo seeking guidance by the packaging committee. Some people in FESCo
are part of the packaging committee even.
> > [...]
>
> And example for a *afaik* (and Michael, please correct me if I'm wrong)
> valid conflicts (it was even discusses on fedora-devel quite some time
> ago iirc):
> libhugetlbfs/libhugetlbfs.spec
> Conflicts: kernel < 2.6.16
> The package for example works fine in a chroot (vserver anyone?) without
> a kernel installed, but on normal machines the installed kernels needs
> at least to be 2.6.16. And the conflicts makes sure that the users has
> none installed that are older -- that's won't work with a Requires (the
> user could still have old kernel around and might accidentally boot into
> it).
Questionable. Superfluous. Dangerous. Blocks kernel upgrades. Tries to
set up artificial hurdles for users of command-line package installers.
FC-6 does only offer a kernel >= 2.6.18, so in an Extras 6 package this
conflict adds nothing else than trouble. Looking for fun with an Anaconda
based dist upgrade?
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--- End Message ---
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
