From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1GvrL1-00049n-Q5 for garchives@archives.gentoo.org; Sun, 17 Dec 2006 08:25:40 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kBH8OlQF015151; Sun, 17 Dec 2006 08:24:47 GMT Received: from spunkymail-a5.dreamhost.com (sd-green-bigip-81.dreamhost.com [208.97.132.81]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kBH8MuuK023619 for ; Sun, 17 Dec 2006 08:22:56 GMT Received: from [192.168.0.100] (c-68-43-193-90.hsd1.mi.comcast.net [68.43.193.90]) by spunkymail-a5.dreamhost.com (Postfix) with ESMTP id 7BC3614D6AB for ; Sun, 17 Dec 2006 00:22:57 -0800 (PST) Message-ID: <4584FC81.4050004@gentoo.org> Date: Sun, 17 Dec 2006 03:14:57 -0500 From: Alec Warner Organization: Gentoo Linux User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Dependencies on system packages References: <20061210011117.36672693@blashyrk> <200612171510.57159.jstubbs@gentoo.org> <20061217070429.126d8364@snowdrop> <200612171641.40343.jstubbs@gentoo.org> In-Reply-To: <200612171641.40343.jstubbs@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 6d1bf1f2-bc29-4802-af7a-b6ce9bb026c4 X-Archives-Hash: 52cd2a5ab7da1c333d93c40595098c21 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. -- gentoo-dev@gentoo.org mailing list