Date: Fri, 17 Apr 1998 14:24:02 +1000 (EST) From: Peter Jeremy <Peter.Jeremy@alcatel.com.au> To: freebsd-hackers@FreeBSD.ORG Subject: RE: Package management (was Re: Come on guys, close a PR or two, Message-ID: <199804170424.OAA24603@gsms01.alcatel.com.au>
next in thread | raw e-mail | index | archive | help
On Thu, 16 Apr 1998 20:14:24 +0200 (CEST), Marino Ladavac <lada@pc8811.gud.siemens.at> wrote: >It would be to our advantage at least to be able to read the SysV >packages. This and Terry's points are good. But you could equally (maybe) say that we should also be able to read RPM packages (for installing shrink-wrap Linux s/w). I'm not sure that we want a single package management tool that can read every format known to man. We'd be better off with a collection of tools that each managed a single type of package, with a UI that hid the details. BTW, how much commercial s/w actually uses that ABI? I manage a couple of Sun's at work. They have a variety of commercial s/w installed on them (eg Interleaf, Oracle, Netscape, Adobe Acrobat, DataViews, Lotus Notes, Tektronix X-terminal s/w, Hummingbird Express/Host, HP JetAdmin, INSO DynaText). Apart from Sun software, the _only_ package that installs as a `standard' SystemV package is JetAdmin. Everything else installs via some non-standard procedure. I've tried (and failed) to convince the relevant groups that our own software should be supplied as a standard package. Is it any different in the x86 area? >As Terry said, we must be able to install such packages. This may >prove crucial in the light of possible x86 UNIX common ABI. This brings up a fairly important point regarding FreeBSD's support for this (potential) ABI. Currently, FreeBSD has its own `native' ABI, with IBCS2, Linux etc all supported via `compatibility' modules. Anyone using (eg) Linux needs a complementary FreeBSD compatibility module (if such a thing actually exists) to run a FreeBSD executable. If agreement is reached on a common ABI, then there are significant advantages in adopting that ABI as the FreeBSD `native' ABI. In particular, this would mean that applications could be built on FreeBSD using the standard development environment and then just shrink-wraped and shipped - making FreeBSD a better choice for a development platform than one with a different `native' ABI. A corollary of this is that the FreeBSD package management tools will need to default to the standard. Of course, Unix does not have a happy track-record of such agreements (BSD vs AT&T, OSF vs USL/UI, (Linux vs itself) vs (OpenBSD vs NetBSD vs FreeBSD) vs commercial Unices), so I don't intend to hold my breath :-(. > support for patches and patch removal) I agree this would be useful (though maybe not as useful as for a commercial, binary-only distribution). The only patch management system I have seen is Sun's - which may install patches as connections of package updates, but has a totally different archive format, tool set and UI. >> 1) Menu-driven interface (in addition to the command line interface). >Sounds fine, but I alone may not be able to implement the front-end. Depending on how fast and efficient the command-line interfaces are, we might be able to implement the front end in curses/Perl or similar, using the command-line tools to actually do all the hard work. This would also make it relatively easy to support multiple, different package formats (as long as the command-line interfaces were not too dissimilar). > The >amount of unpacking necessary to retrieve the dependency info should be >reasonable (i.e. tar xf -fast package header). The problem is that (as far as I can tell) there's no way to tell tar to stop after it unpacks the first occurrence of a file - it continues to the end of the archive in case a later copy was appended. >> 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. The problem is that this makes the package much more difficult to manipulate via standard tools. On several occasions, I've wanted part of the contents of a package, but haven't wanted to install the package - this is more painful if you have to cut bits off the start of the package before you can feed it into a standard tool. I like Eivind's suggestion of ZIP, except that it's not part of the base system and can't manage stream archives. >> 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). I realise that. That's why it's the lowest importance. Note that if you have a staging area, you are automatically up for an (unnecessary) disk-to-disk (or maybe swap-to-disk) copy of the unpacked archive - which is also slow. I'm primarily thinking about being able to install a large package (eg emacs or Interviews) on a system without much free temporary space. And one requirement I left off was that is needs to be relatively easy to create packages (ie write the install driver file). I've previously avoided using the SystemV packages for this reason (I actually wound up using the FreeBSD package management as a base). >> Unfortunately, at this stage, I don't have the spare time to actually >> implement suitable tools. >This is unfortunate :( I'd like more free time as well. I'll help where (when) I can. Peter 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?199804170424.OAA24603>