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 _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
