From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JC1cq-000190-VA for garchives@archives.gentoo.org; Mon, 07 Jan 2008 23:43:25 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BF5BDE0818; Mon, 7 Jan 2008 23:43:22 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 6B5E3E0818 for ; Mon, 7 Jan 2008 23:43:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id DEB3964D23 for ; Mon, 7 Jan 2008 23:43:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 required=5.5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVL9GVWkfOIR for ; Mon, 7 Jan 2008 23:43:15 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id C0B3A6502F for ; Mon, 7 Jan 2008 23:43:12 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JC1cX-0001tI-3J for gentoo-dev@gentoo.org; Mon, 07 Jan 2008 23:43:05 +0000 Received: from adsl-ull-74-61.48-151.net24.it ([151.48.61.74]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Jan 2008 23:43:05 +0000 Received: from flameeyes by adsl-ull-74-61.48-151.net24.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Jan 2008 23:43:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: flameeyes@gmail.com (Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?=) Subject: [gentoo-dev] [RFC] Reducing the size of the system package set Date: Tue, 08 Jan 2008 00:42:57 +0100 Message-ID: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: adsl-ull-74-61.48-151.net24.it User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:gGxjOZYNngfiXMcRcYJAwcAhhBI= Sender: news X-Archives-Salt: 159126be-0582-453d-9026-f7e39f96cf12 X-Archives-Hash: 155ea6269581c002e41f7791434627c2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here comes the official proposal, copy and paste from my blog with an extra post scriptum at the end. I already ranted about the fact that the dependency tree of our ebuilds is vastly incomplete, as many lack dependency on zlib; trying to get this fixed was impossible, as Donnie and other insisted that as zlib was in system, we shouldn=E2=80=99t depend on it at all. I disagree, and I would like to know why we can=E2=80=99t depend on a system package, but whatever. Anyway, as having a complete dependency tree is almost impossible because of that, I have an alternative proposal: reducing the size of the system package set. Right now system contains stuff like ncurses, readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so on. Those are packages that certainly would be part of any base Gentoo system, but are those actual part of the system set of packages? I sincerely doubt it. The reason of the existence of the system package set is related first and foremost to breaking circular dependencies: for instance if any package that used the C compiler would depend on gcc, then the packages that gcc depends upon would create a circular dependency between gcc and itself. Also, specifying libc in almost any ebuild would be quite pointless, as well as coreutils (or freebsd-bin/ubin) for cp, mv, install, =E2=80=A6 But why autoconf and automake? Well the easy answer is that those are often used without making sure they are depended upon explicitly=E2=80=A6 o= r at least this was the case till me and Martin added autotools.eclass to the tree; nowadays all the ebuilds using autotools should have proper autoconf/automake dependency already, and if they don=E2=80=99t they are br= oken anyway. So why leaving them in system? And what about m4? m4 is not part of a common Unix system, it=E2=80=99s just an autoconf dependency, why isn= =E2=80=99t it just an autoconf dependency? For what concern the three main libraries, there aren=E2=80=99t that many packages using zlib directly nowadays, this is especially easy to spot on a system built with --as-needed, as without that you actually do see zlib used in every other binary, for indirect dependencies. Nor there aren=E2=80=99t tons and tons of packages using readline, or ncurses. Actual= ly in my own vserver=E2=80=99s chroot I only found four packages using readline, = none of them part of system: ruby with the readline extension (uhm I wonder if I should ask for this to become an USE flag, I certainly don=E2=80=99t n= eed it and I=E2=80=99d rather get rid of it), psql from postgresql (which maybe= it=E2=80=99s still good to have with readline compiled in, but I could easily get rid of), bc (which is just an e2fsprogs build-dep, and I could build without readline just fine), and mysql. A little bit different the status of ncurses, which is used by screen, gettext (only a build-dep, not needed for runtime on Linux anyway), procps, psmisc and util-linux (and I wonder why we don=E2=80=99t have a swi= tch to turn it off), texinfo (wonder why we can=E2=80=99t remove it entirely actually) and yet again ruby. Still, I wonder why ncurses is in system rather than being properly on the dependencies list of those packages. As for perl, that=E2=80=99s probably a bit more justified, there are tons of packages using perl directly or indirectly, especially in build systems. But I would like those to depend on perl properly rather than having perl in system, as there are cases where perl is not really needed at runtime at least. And the only users of gnuconfig are the packages making use of the old and deprecated gnuconfig.eclass, or portage=E2=80=99s econf. Why can=E2=80= =99t it be a dependency of portage then? There are probably other packages that should, in my opinion, be removed From=20system, but these are certainly some of the most common. Unfortunately there=E2=80=99s a recursive problem here: to remove t= he packages from system without breaking stuff you=E2=80=99d need a proper dep= tree, and to get a proper deptree you need to remove the packages from system. This is what actually stops me from proposing this right away=E2=80= =A6 P.S.: So there are more things that were brought to my attention, like ssh, flex, bison, e2fsprogs, and so on. We should probably look into what to keep, rather than what to remove. Also, rocket proposed me to try building a stage with a slimmed down system. I could try, but it would be a waste of time if we then decide not to go this route, and that's _a lot_ of time that would go to waste, so I'd rather first see what the other devs think, before going to do the actual tests. =2D-=20 Diego "Flameeyes" Petten=C3=B2 http://farragut.flameeyes.is-a-geek.org/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (GNU/Linux) iEYEARECAAYFAkeCuQEACgkQe2h1+2mHVWMgegCfdZEzC7BwT2SLUqKHDOM8g6SL KMIAoPKunIvODl5EA8yQTI2U4LbYtG9R =EPmA -----END PGP SIGNATURE----- --=-=-=-- -- gentoo-dev@lists.gentoo.org mailing list