From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28327 invoked from network); 27 Oct 2004 22:45:35 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 27 Oct 2004 22:45:35 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CMwXv-0004xS-Ec for arch-gentoo-portage-dev@lists.gentoo.org; Wed, 27 Oct 2004 22:45:35 +0000 Received: (qmail 24304 invoked by uid 89); 27 Oct 2004 22:45:34 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 7229 invoked from network); 27 Oct 2004 22:45:34 +0000 From: Ned Ludd Reply-To: solar@gentoo.org To: "Peter S. Mazinger" Cc: gentoo-portage-dev@lists.gentoo.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uQKlKJtqwC/sAsG+U4pZ" Organization: Gentoo (hardened,security,infrastructure,embedded) Developer Message-Id: <1098917030.458.213.camel@simple> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 27 Oct 2004 18:43:51 -0400 Subject: [gentoo-portage-dev] Re: mkinitrd X-Archives-Salt: 03fdc532-6087-457c-bf41-64777b1d1b3b X-Archives-Hash: fe1a0798929ed2201eb1de57f310a031 --=-uQKlKJtqwC/sAsG+U4pZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-10-27 at 15:20, Peter S. Mazinger wrote: > On Wed, 27 Oct 2004, Ned Ludd wrote: >=20 > > I've been thinking about initrd and I'd like to move down that path at = some point for my own use. > > Perhaps kernel+busybox for the initd then another partition for package= s. > > I'd like to go right from building packages on my own system to dishing= (http:// || ftp:// ) them up from my $PKGDIR and installing right to the d= evice when it's mounted +rw. > > Problem I see however with the idea now is that the native portage form= at is a tad bloated (noman|nodoc|noinfo) all run at the installing phase vs= the before packages phase which would force me to put a strip on the runti= me device to keep packages small enough. > > So my first goal is to get the dev-portage guys talking with me about r= edefining/extending the portage binary format a little. > >=20 > > hrmm I guess I'll subscribe to gentoo-portage-dev-subscribe@gentoo.org > > and spark up a conversation. >=20 > Are you thinking of adding subpackaging and/or foreign format support,=20 > like ipkg? I have very simple ways todo ipkg format now that I can share with you if y= ou want to deploy it now.=20 But the topic of binary format handling is a hot topic (but nobody is reall= y talking about it) Guess I'll CC: this to gentoo-portage-dev as my first post. Right now portage only handles the .tbz2 format. This current format poses = a few problems for it to really be useful for us on embedded devices.=20 The tarballs contain man files/docs/info pages (lots of bloat to us). None= of the ELF's are stripped in the package. Normally on our development systems we don't see these files as they don't = get installed to the runtime system because FEATURES=3D"noman noinfo nodoc"= are set and this is handled in the dyn_install phase. So in order to get t= he desired behaviors inside we want it's almost like we need to do. emerge pkg ; quickpkg pkg vs emerge -B package Another problem that exists for us is that embedded systems usually never h= ave python/perl/(your fav scripting lang here) installed. Without python in= stalled I see no easy way to get at the additional package metadata thats j= oined into the .tbz2 This metadata is what holds the basic info like (what arch is this package = for. USE/IUSE etc..) but even half of that is sealed up in a file called en= vironment.bz2 so we have to decompress & extract the entire .tbz2 then pars= e (not source) the decompressed 'environment' file just to find out if a pa= ckage is for our ARCH or not. This is by no means very efficient. Also the INSTALL_MASK feature needs work ( http://bugs.gentoo.org/show_bug.= cgi?id=3D67190 ) Now to answer your orig question. ipkg format. This is sorta of a yes & no thing. In order for portage to be= tter support more formats it should have abstraction layers between diff fo= rmats. So first we must decide what formats we want to support.=20 I'd think out of the gate we should support the most primitive of these pkg= formats which is the classic .tar.gz (.tgz) format for the actual file sys= tem data. Note to self:=20 Look at source code for /usr/bin/tbz2tool (busybox emerge binary applet?) >=20 > Peter --=20 Ned Ludd Gentoo (hardened,security,infrastructure,embedded) Developer --=-uQKlKJtqwC/sAsG+U4pZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBgCSm94CCfB4KcwwRAk3EAKCgDt+rwSXKybFOdSk/IyKCZwZSuwCff+cL hh7ZBmJQ+HW04uqdXdAcnNM= =1E8v -----END PGP SIGNATURE----- --=-uQKlKJtqwC/sAsG+U4pZ--