Jason Stubbs wrote:
There's ways to manage this complexity, such as putting the dependencies into
autotools' RDEPEND (if it can be considered correct) or by using
meta-packages. However, your point is against requiring that packages _must_
specify all system dependencies. While I personally believe that packages
should specify all dependencies, what I'm arguing against is requiring that
packages _must not_ specify any system dependencies.
--
Jason Stubbs
I agree with your personal belief, however I also find it unmaintainable
in the current system (metapackages in their current form
non-withstanding as I don't think they are a great solution, merely duct
tape if you will, but that is another discussion entirely).
There is no benefit for me as a package maintainer to dep on a system
package unless there is an existing problem. From a maintainer POV it's
extra work and extra writing to keep the deps up to date. Also there is
the whole thought of what to list? Do I list only glibc versions that I
know work? gcc versions that I know compile my code? Where does the
line get drawn? What is the point of depending on certain elements if
say, they are already a dependency of $PACKAGE_MANAGER? It is not
pragmatic for a distribution to do so IMHO, 'technically correct' or not.
A few use cases that would go against this involve people doing odd
things like emerging a bunch of stuff and then unmerging a critical
system package (say, ncurses); since my program happened to depend on
ncurses anyway it would 'fix' the problem automatically for the user
instead of dying with no ncurses. Of course this use case could be
handled another way; by having portage make sure that packages listed in
'system' are installed. While I am a fan of the 'fix it automatically
in DEPEND' way here; the use case is rather...convenient. Unmerging
many things in system either break portage, or won't affect anything (oh
no I unmerged virtual/editor!)
So yeah, in conclusion; too much work, fix it when it's reported broken
seems like a decent (pragmatic) policy to me. If/When it becomes easy
to list stuff (package sets or something, please not metapackages in
their current form) then I'd be much more interested in implementing it.
As an aside, If you are unsure in a given situation feel free to ask
someone about it. Worse case you (put an extra dep in|leave out a dep);
both are easily repairable.
--
[email protected] mailing list
