Date: Thu, 16 Apr 1998 20:14:24 +0200 (CEST) From: Marino Ladavac <lada@pc8811.gud.siemens.at> To: Peter Jeremy <Peter.Jeremy@alcatel.com.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: Package management (was Re: Come on guys, close a PR or two, Message-ID: <XFMail.980416201424.lada@pc8811.gud.siemens.at> In-Reply-To: <199804152224.IAA03296@gsms01.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15-Apr-98 Peter Jeremy wrote: > Some disadvantages of the SysV package style (or at least Sun's > implementation thereof): > 1) There's no provision for compressing the package. This is fairly > essential for Internet-based distribution. This is a minor issue: I wrote SysV style, not SysV reimplementation. It would be to our advantage at least to be able to read the SysV packages. We can have our own stream format (used by default when packaging) consisting basically of a header and a tar-gzipped data tarred together. The header shall contain all dependency info, at least. This is not unlike the present package format. > 2) The `datastream' format can only be understood by the package > management tools - whilst the guts are a cpio (yuk) archive, > there's a header that needs to be stripped off before cpio can > understand it. As Terry said, we must be able to install such packages. This may prove crucial in the light of possible x86 UNIX common ABI. Furthermore, additional extensions (prepackaging and postpackaging actions, support for patches and patch removal) have proven themselves as advantageous in practice. I intend to build a generic extension mechanism into prototype syntax. > My suggestions for the requirements (in order): I agree with your requirements, and have some additional comments: > 1) Menu-driven interface (in addition to the command line interface). > The current pkg_manage is probably OK as a UI, but is incredibly > slow (because of the amount of package unpacking it does). Sounds fine, but I alone may not be able to implement the front-end. The amount of unpacking necessary to retrieve the dependency info should be reasonable (i.e. tar xf -fast package header). > 6) Package contents and description can be determined quickly (ie > without unpacking the entire package) Header extraction should suffice. > 8) Package contents can be extracted using normal tools (eg tar, gzip) > if necessary (this may be mutually exclusive with 6 above). Not necessarily. The header should contain the complete prototype which is just plain old ASCII. > 9) Packages can be installed without requiring a staging area equal in > size to the unpacked package. This may prove to be difficult (or slow). Would you agree to the staging area as a default optimization? > > Unfortunately, at this stage, I don't have the spare time to actually > implement suitable tools. This is unfortunate :( /Marino ---------------------------------- Marino Ladavac Date: 16-Apr-98 Time: 19:43:01 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980416201424.lada>