Alec Warner wrote: > 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. > I agree but I don't think Jason was saying that; just that he should be /allowed/ to specify a dep; clearly it should be exceptional, and maybe tracked as an issue with the pkg.
As you mention the worse is that an extra dep goes in. But if we take the time to hammer out the policy now (so far I'm reading don't put in a system dep unless you really have to, and even then it may indicate an upstream problem) it'll at least be clear. -- gentoo-dev@gentoo.org mailing list
