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.43) id 1E7dOM-0000sp-4M for garchives@archives.gentoo.org; Tue, 23 Aug 2005 18:20:58 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7NIJNVM021539; Tue, 23 Aug 2005 18:19:23 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7NIHdvS025266 for ; Tue, 23 Aug 2005 18:17:40 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E7dM1-00015d-4d for gentoo-dev@lists.gentoo.org; Tue, 23 Aug 2005 18:18:33 +0000 Date: Tue, 23 Aug 2005 13:17:15 -0500 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] stripping implementation in portage Message-ID: <20050823181715.GB28369@nightcrawler> References: <20050822223849.GW10816@nightcrawler> <200508231116.56154.pauldv@gentoo.org> <1124818473.12024.76.camel@cocagne.max-t.internal> <20050823174021.GA28369@nightcrawler> <1124819926.12024.80.camel@cocagne.max-t.internal> 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline In-Reply-To: <1124819926.12024.80.camel@cocagne.max-t.internal> User-Agent: Mutt/1.5.8i X-Archives-Salt: d668d4b9-5ba0-4d07-89ee-c0bae672c57e X-Archives-Hash: faadafbb4bcc12fdc13e03f1127dd9e2 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2005 at 01:58:46PM -0400, Olivier Crete wrote: > I havent looked at your new implementation (does it exist).. but yea > what you wrote seems to make sense... except that I keep the source code > too.. so it would bloat binary packages.. I think it should be done > before the packages are made.. or maybe use separate debug and have > separate debug packages like RedHat does. Your choice of what goes into the binpkg is just that, your choice,=20 just the same as your choice of what ultimately hits the livefs. Bit of a shift in terms of how things are designed; repositories are=20 base objects, things like package.* filtering and changing=20 (package.use) is implemented as wrappers of the repo. Wrapper base is=20 implemented, as is the filtering wrappers; for what's discussed above,=20 just need to design an appropriate contents filter. Re: does it exist, yes (in cvs, and now living in svn), better=20 question, is it usable yet, no; core was yanked, rebuilding it. This=20 is a sizable chunk of why feature requests are on hold- either more=20 crap gets duct taped into portage, or design is corrected so=20 features/additions/tweaks/whatever is easier to do. Long term=20 maintenance/extensibility vs short term gain is the crux of it. What you're after can be pulled off, and the specification of what=20 type of stripping to do can be left to the user's config for that repo;=20 intention is to allow you to strip sources for binpkgs fex, while not=20 stripping sources for livefs merge. =20 Just a question of how you define your config; the restriction/depends=20 bit referenced in the other thread relates to this, you define the=20 classes needed and define your config to use them, using alt. formats=20 should be possible (exception: OE format I don't see any way to=20 support of what I know). So... the sources concern is moot. Hell, via the wrapper approach if you= =20 wanted you would be able to define your own wrapper that splits a pkg=20 into chunks, or have the repo do it. Don't really care what you do,=20 just care correcting underlying issues, and having the remaining beast=20 flexible so people can do whatever crazy crap they want instead of=20 directly hacking portage innards. Sidenote, wrapper approach is how install_mask/no{man,info,doc} will=20 be defined, rather then jamming crap into the core. Define it as=20 seperate chunks, and you can arbitrarily arrange it, doing whatever=20 the hell you want. ~harring --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDC2grvdBxRoA3VU0RAksbAKC+uIFRiQPTnvDxNoB3M1Y1XzmyMgCg4OZE CtkpUePCptHFcudWIlZHuCY= =wqJg -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- -- gentoo-dev@gentoo.org mailing list