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

Re: Dependency loops considered harmful?



On Wed, Sep 3, 2008 at 8:58 AM, Miroslav Lichvar <mlichvar redhat com> wrote:
> What do you think? Are loops something that we should try to avoid?

generally speaking...yes..make a reasonable effort to avoid loops.
But that isn't a strict requirement. If a maintainer fills there is a
good reason to have a loop, then they can do it. But we should
probably ask them to document that reason in the spec file when they
are making a deliberate decision to form a loop.

Though I will say that loops that involve docs or devel subpackages
are probably packaging errors and you could probably get them fixed up
by talking with the maintainers.  I would be surprised if a docs or
devel subpackage was intended to be required with the main package.

the -libs subpackage situations.. im not sure about.  I think its case
by case.  Does kde3base-libs need kde3base? I dont know.  Does
oddjob-libs need oddjob?
For the -libs circular loops I think some might be packaging errors
and some might be deliberate choices. We should probably try to get
the maintainers to make spec comment in the cases where its
deliberate.

the -data situations are probably deliberate, as a way to make sure
that an application cleans up after itself when uninstalled.

For the more complicated situations in your groupings.... that's
definitely going to be case by case.  I'm pretty sure the Xorg
sitaution is deliberate to ensure some basic hardware support is
installed.  Things are broken out modularly as packages so individual
drivers can be updated without pushing the whole Xorg tree as an
update, but we still want some basic driver support always
installed..hence the circular deps.

But the zlib loop? It touches so many packages I'm not sure it could
be deliberate decision.  Can we avoid it? I don't know...it would
require the maintainers of all the packages in the loop to talk about
it.

It is a bit of interesting analysis.

-jef


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