Subject: Re: Proposal: new binary package format
To: Matthias Scheler <firstname.lastname@example.org>
From: Hubert Feyrer <email@example.com>
Date: 05/31/1999 03:03:48
On 31 May 1999, Matthias Scheler wrote:
> Because of the problem above I would like to design a new binary package
> format with these features:
> - fast access to the private files
> This could be done with two stage archive like e.g. the ".deb" format.
> Such a file can still be extracted with standard tools.
You mean, like keep all the +-files in a .tgz (or something), and include
that as first file in the binary package?
> - support for multiple directories
> Simply store files with absolute filenames.
Probably the saned thing to do, given that few and fewer packages can be
relocated these days. We'd need to accompany changing LOCALBASE/X11BASE,
> Because we need a redesign of the package tools anyway I would also
> like to invent a bunch of new commands for package lists:
> - @tree <dirname>
> Track all files, directories and links in the specified directory.
> This could e.g. be used for "share/doc/pkgname".
RPM allows simply adding a directory to their PLIST(aequivalent), and TRT
> - @symlink <from> <to>
> To get rid of all those "@exec ln -fs ... ..." lines.
... and probably the accompanying @unexec lines.
> - @config <filename>
> Files with this tag should
> - only be deinstalled if a "complete" package removal is requested
> via a special "make" target or option to "pkg_delete".
> - not be monitored for checksum changes.
> - Not be overwritten during "make install" or "pkg_add".
I'd suggest doing this a bit different.
1st, don't leave the file back on pkg_delete, but move it aside.
That way, nothing gets lost, and any new package can add
a new config file, which may be incompatible with the old
one. Still, the old one will be available for reference.
You can do this my just "mv file file.old".
2nd, we may even call the @config with two arguments. One that specifies
the final filename of the config file, and another one that gives
the filename of a template file that may be copied to the final
location (automating this process).
I can even imagine specifying custom commands for #1 and #2, i.e. instead
of "mv file file.old" and "cp template file" use something like "rm file"
and "cp template file ; ci -l file".
When will you be done? :-)
NetBSD - Better for your uptime than Viagra