Fedora Alternatives (Re: [fab] build service)

[Thorsten Leemhuis]

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