Date: Tue, 31 Oct 2000 10:44:38 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: kientzle@acm.org 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: <39FE2406.150CA3B1@newsguy.com> 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> <39FDC12E.304B0011@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim Kientzle wrote:
>
> > 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
Precisely. You cannot do random access with single stream compression.
We _need_ to avoid single stream compression if we are to have random
access, which we happen to want. Well, Jordan does, I just work here.
:-)
> 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.
This very unusual for ports. Few small text files, or many text files,
some small some large, are the common cases. We should target the common
cases.
> 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.
It would surprise me. I think you are grossly overestimating tar.gz
advantage. Anyway, the ports tree is very different from the source tree
or the ports sources.
> 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.
I predict that in two or three years, we'll be using DVD. The argument
still holds true for network connection, as I *do not* predict wideband
access _world wide_ in two or three years.
> compress-then-archive (ZIP, etc.) gives quick single-file
> access at the cost of bigger archives.
Yep.
> 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.
Package installation can be painfully slow because of tar.gz problems.
Compare the speed with which our packages are installed with the speed
of the most popular Linux package formats. We can be two times slower
than them.
> (That 20% figure is just a guess based on my experience with
> the different formats; it could be lower, could be much higher.)
I think that 20% figure is way out of proportion. I doubt the difference
would go as high as 10%, based on my experience.
> > 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
Nope, as far as I know, we DO NOT want to move away from our model. I,
and a lot of people I have heard from, consider the centralized model we
use to be one of FreeBSD's main advantages over some Linux
distributions. Then again, maybe the mood has changed from the last time
I saw this issue discussed, but I'd rather believe to still be in the
majority. :-)
Besides, that doesn't really address what I said. It's the USER who
specifies what should be done. The package says "install to /bin", and
the installation installs to "${PREFIX}/bin". By the default, for ports,
that prefix is /usr/local. The distributions would have a prefix of /.
If the user makes it / for a package install, do what he says.
> 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.
Not true. We don't have much of a problem with overwrites, except for
multiple versions of the same software. The later is an upgrade target
problem, not a problem in itself. Programs, like tcl, which one would
naturally want multiple versions of are installed without conflict.
As for /usr/local being shared with locally compiled software... well,
that's only if you want it to! :-) You may either install the locally
compiled software elsewhere, or you may put a different base path for
ports/package installation on /etc/make.conf, and still preserve the
single directory for all ports model.
> > 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.
Somehow I dislike PATHs, MANPATHs and LIBPATHs with 40 or 50 entries, I
dislike a /usr that won't fit in one screen, I dislike having programs
all over the place, I dislike having to edit /etc every time I want to
make a new program available, and I specially dislike having to instruct
users in setting up their accounts to be able to use a new program .
Install/deinstall is simple. It's in the database, so I have no problem
telling one software apart from the other in the directories they share.
I don't even _need_ to, as it's automated. It's the non-automated tasks
that get more complex going from the single-directory model to the
multiple-directories model, which I used on AIX, Ultrix and SunOS. Using
both at the same time, I would sometimes sigh in relief when I had to
deal with something on FreeBSD instead of the others.
> 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.
Well, *don't use* /usr/local! Use something else. Or install the ports
on /opt or whatever, and keep local to yourself, though that seems to me
to be needlessly straying away from the standard way we do things.
This argument is without merit, imo. If you are mixing locally compiled
software, over which you have complete control over install path, with
the ports, that's exclusively *your* choice, with which our ports model
have *no* connection.
> 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.
Not really. All ports are built and installed in the directory
${PREFIX}. If you want elm+ME to be installed on /usr/elm+ME, you type
PREFIX=/usr/elm+ME make all install
So, as you see, the install place is *NOT* fixed at all! The default, in
the absence of PREFIX, is /usr/local, but the argument that having this
as default simplifies things from a build/install perspective is
incorrect.
--
Daniel C. Sobral (8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@world.wide.bsdconspiracy.net
He has been convicted of criminal possession of a clue with intent to
distribute.
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?39FE2406.150CA3B1>