[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: broken deps outside of packagers control

On Fri, 20 Apr 2007 09:13:27 +0200, Hans de Goede wrote:

> > Nothing I will address, because the Fedora multi-lib strategy is close to
> > undefined. Whether tools would create/update/maintain the white- and
> > black-lists or whether packages would be selected manually, is not
> > anything that is worked on officially and visibly.
> > 
> So you do agree with me this is a problem? Remember this whole discussion 
> started because of you saying that the fix for broken deps, caused by the 
> current not smart multilib strategy, was to just remove the -devel sub packages 
> or kludge around otherwise. 

No, you twist words here and mix things up.

It is not my general advise to eliminate -devel packages as the one and
only way to get a package excluded from the multi-lib resolver. I always
point out that packages can be put onto the blacklist.

It is not documented anywhere, however, as what packages we do want as
multi-lib. For many application packages, which have a -devel sub-package,
it *is* possible to split off the libraries (as Peter Gordon has pointed
out in this thread), so the -devel package no longer requires the main
application package, but only the -libs package. That results in an
increased number of packages, and is argueable, but for some types of
packages it does work. And again, whether we want that for all small
applications is questionable and not covered by any guideline.

On pygame: When I skimmed over the contents of pygame-devel in Dec 2006,
the first file was a pure C header without any Python stuff in it and
without any corresponding library to link to. That put me on a false
track. I should have looked less briefly, since macros in the other three
headers do import Python modules via the Python C API. Christopher was
free to point out my mistake instead of eliminating "Requires: Python-devel
SDL-devel SDL_mixer-devel" without any replacement. He could also have
consulted the original reviewer of the package and request a second

On gnumeric: The package name alone is not enough to decide whether to
make it multi-lib. Also your proposed wildcards would *not* have excluded
it by default. Perl.i386 was available for x86_64 for a long time (see
e.g. FC6), and simply nobody has noticed so far that gnumeric-devel and
gnumeric are broken, at least a bit:


You can prove me wrong. Maybe where my brief look found a missing
executable, an unexpanded variable and a superfluous symlink, there is a
way to fix all that without ending with an empty gnumeric-devel package.
But without looking into it, please don't suggest that a separate
gnumeric-devel package for a single *.idl file is justified. Finally,
if there is no way to avoid the gnumeric-devel package (e.g. after
fixing the package contents), it *is* possible to blacklist it for
multilib -- and it is on the blacklist already as Fedora 7 is getting

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]