Date: Mon, 30 Oct 2000 10:42:54 -0800 From: Tim Kientzle <kientzle@acm.org> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Alexander Langer <alex@big.endian.de>, libh@FreeBSD.ORG, "Jordan K. Hubbard" <jkh@FreeBSD.ORG> Subject: Re: BOF at BSDCon: FreeBSD Installer, Packages System Message-ID: <39FDC12E.304B0011@acm.org> References: <39DCC860.B04F7D50@acm.org> <20001006155542.A29218@cichlids.cichlids.com> <39F3CDD7.15B889E7@acm.org> <20001023190412.B507@cichlids.cichlids.com> <39F47E98.4BB647AA@acm.org> <20001023202244.B10374@cichlids.cichlids.com> <39F48F4A.38D458C2@acm.org> <39FCF244.5A8C8E59@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Daniel C. Sobral" wrote:
> Tim Kientzle wrote:
> > * ZIP access? Have you written your own, or just incorporated
> > pre-written libraries? [ List of problems with ZIP ]
>
> Heh. I also thought the ZIP thing wasn't very well thought out. I wonder
> what other formats we could use... ARJ? RAR? LHA?
Unfortunately, all of those share ZIP's problem with poor
compression (relative to tar.gz, at least). ZIP, ARJ, RAR, LHA,
ZOO, ARC, StuffIt, etc, etc, all compress individual files and then
create an archive from them. tar.gz creates the archive then
compresses it all as a single stream. I've seen many instances
in which tar.gz files are half the size of ZIP files. This is most
pronounced with archives containing a lot of small text files.
Though I haven't tested it, I wouldn't be surprised if
the ports tree was more than twice as large in ZIP format as
in tar.gz format.
There's a very simple trade-off:
archive-then-compress (tar.gz) gives smaller files (and
therefore fits more stuff onto the installation CD-ROMs)
at the cost of more tedious single-file access.
compress-then-archive (ZIP, etc.) gives quick single-file
access at the cost of bigger archives.
Pick one. Personally, I think the most important issue is to
be able to build full-featured distributions, which means sticking
with high-compression formats such as tar.gz. Package installation
is not a particularly time-critical operation, so I don't see
fast single-file access as a sufficient imperative to justify
losing as much as 20% of the current CD-ROM distribution.
(That 20% figure is just a guess based on my experience with
the different formats; it could be lower, could be much higher.)
> > * Consolidating package/distribution formats needs to be done
> > carefully. In particular, there are different security issues:
> > e.g., packages should generally be prohibited from dropping bits
> > into /bin or /etc.
>
> Non-sense. Packages should do what they are told, period. Do not
> "forbid" anything.
>
> Besides, all paths in a package MUST be relative to the base directory.
> I might want it installed on /usr/local, /opt, or even /. Thus,
> distribution formats need not be any different from package format.
Having a package just be a list of instructions to be blindly followed
is acceptable as long as you assume everyone always pulls their packages
from a "trusted" source. My understanding was that people wanted
to move away from the assumption of a single, universally-available
trusted source. That doesn't mean the basic format for distributions
and packages can't be the same, but it does mean that there need
to be different security models for them. The simplest security
models I've been able to come up with are:
* "distributions" can put anything anywhere they want
* "packages" can only put files into a single directory owned by
that package; any exceptions must be specifically listed in the
manifest and may be subject to manual approval by the user.
Either, of course, may be subject to cryptographic authentication.
(The expiration of the RSA patent simplifies this issue considerably.)
If you can suggest an equally simple security model, I'd be interested
in seeing it. I think this model is simple, robust, easy to understand,
and allows for several different implementation approaches.
Putting all packages into /usr/local begs problems with file overwrites
(which can't realistically be resolved manually; even when you can
tell the user what package each file came from, few users will be
able to tell whether it's "safe" for a particular file to be replaced)
and creates other ugly problems because /usr/local must generally be
shared
with locally-compiled software.
> > * An idea that gets floated around periodically, but never apparently
> > taken seriously: packages should install into private directories.
> > /usr/local is becoming a real tarpit. Instead, package foo-3.4 should
> > be contained _entirely_ (with few exceptions) in
> > /usr/packages/foo-3.4/
>
> Err... no. This is a worse nightmare. Ok, you might disagree. You have
> the option of changing the base path of the port to be installed. Write
> a shell script that makes the install path get it's name from the port.
"a worse nightmare"? I'm curious to know why you think this.
I used exactly this approach on my own FreeBSD system for several
years, and found it quite managable. I'd be interested in knowing
what problems you've had with it, as I've found it a big improvement
over the current /usr/local tarpit.
For the last two years, as an experiment, I've tried using the packages
system "straight" to see how it works. In short, it's rather a
mess and something I'll soon be dumping. The current packages system
is, in my opinion, acceptable only if you assume that noone ever
manually compiles their own software.
In particular, some of us would like to use /usr/local for
locally-developed
software, or need to track certain open-source projects (I'm currently
tracking "Tomcat" and have closely followed "latex" in the past), which
means that /usr/local becomes a mix of package-installed software and
manually-compiled software. This is not a viable situation.
As far as I can tell, the /usr/local mess is a somewhat delicate
issue exactly because so much currently-distributed software
currently installs by default into /usr/local. By using /usr/local
for packages, that simplifies building ports, since many software
packages require little or no change; on the other hand, most
locally-compiled software is also going to end up in /usr/local,
which argues for keeping packages out of /usr/local.
- Tim Kientzle
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?39FDC12E.304B0011>