Date: Fri, 9 Aug 2002 01:26:33 -0700 From: Jordan K Hubbard <jkh@queasyweasel.com> To: Antoine Beaupre <anarcat@anarcat.ath.cx> Cc: libh@FreeBSD.ORG Subject: Re: package format and creation Message-ID: <B6911A7E-AB71-11D6-8CFD-0003938C7B7E@queasyweasel.com> In-Reply-To: <7F90C363-AA43-11D6-9D65-0050E4A0BB3F@anarcat.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, August 7, 2002, at 01:23 PM, Antoine Beaupre wrote: > 1- zip file (current package format): allows comment and customizable > inline archive properties, random access and moderatly powerful > compression > 2- FS image (ISO, FFS or else, possibly compressed): random and fast > access, compression dependent on the system's facility to mount > compressed images, might be requiring temporary extraction space > 3- .tar.[gz|bz2]: no random access without temporary extraction, > powerful compression > 4- .foo (insert you favorite archive scheme): must allow good > compression, preferably accessible through library calls, preferably > also allow random access > > It's been originally thought the zip file was the best choice. I still > think it's a pretty good choice, but the FS image format is very > attracting too. Obviously if the target format has a rich enough collection of attributes to meet libh's minimum requirements, it should be a possible "output" format for the package generator. I agree that this can and should be reasonably abstracted so libh isn't locked into any one format (say there were a big lawsuit over zip and suddenly we had to abandon it as GIFs were abandoned for jpegs). The only thing currently driving zip is that it meets the requirements nicely, but that's not to say that it will always be the only reasonable format. > How is a package created? The current pkg_tools scheme is not good > enough since it requires installing *and* registering the package in > the system to package it, which is a bit absurd. The current libh > scheme is a bit better since it installs the thing in a temporary > location. > > We can do better. Good luck.. :-) There's nothing absurd, unfortunately, about the sheer amount of software out there which through its build procedures or its code depends on having things in a fixed location. When you run the configure script for program A which depends on program or library B, those fancy configure scripts will prowl the system looking for B in all of its "canonical locations" will either fail to locate it if it's not in those places or, once they find it, will compile right into program A the location of B. If you then move B elsewhere, program A will break. Even without dependencies, program A will very often hard code the dependencies it has on its own internal components (like doc or config files) and will derive those paths from its build phase. Do you really want to "fix" all of that software as a prerequisite to packaging it with libh? I honestly don't think so, and the sheer pain of making things relocatable will be large enough that it in itself will become a significant barrier to entry for new package writers if you mandate it as part of the system. The FreeBSD ports collection side-steps a LOT of hairy issues by simply installing a dependency fully and to its final destination before going back to the depending port and resuming its build. The same situation maps to pkg_add. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B6911A7E-AB71-11D6-8CFD-0003938C7B7E>