Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 02 Nov 2000 11:07:39 +0900
From:      "Daniel C. Sobral" <dcs@newsguy.com>
To:        kientzle@acm.org
Cc:        Patrick Bihan-Faou <patrick@rageagainst.com>, libh@FreeBSD.ORG
Subject:   Re: Making the Packages System Better
Message-ID:  <3A00CC6B.39522CF0@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> <39FE2406.150CA3B1@newsguy.com> <00cb01c042f1$1a347190$040aa8c0@local.mindstep.com> <39FE562C.714DBE7C@newsguy.com> <39FFCD73.7364C2BF@acm.org> <39FFE5B7.8FC4216B@newsguy.com> <3A0063F5.4798055B@acm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Tim Kientzle wrote:
> 
> * Vague "I don't like it" comments.

Symlinks are annoying for many people, which is one of the reasons they
prefer BSD rc over SysV init.

> So far, I've seen exactly two valid technical objections:
> * symlinks slow down file lookups.  I don't know
>   any good way to solve this one.  Hardlinks would
>   solve this issue, but would make link directory
>   maintenance considerably uglier.
> * symlinks confuse programs that look for their
>   data files relative to the executable location.
>   One past culprit was the JDK, but that's been
>   fixed in later versions.  For other programs,
>   you can mindlessly create a one-line shell-script
>   wrapper that invokes the real program in it's
>   package directory.
> 
> This is more-or-less the system I'm going to be using;
> if the FreeBSD "package" tools don't support it, I won't
> be using them.  No great loss, personally, but I
> just thought it would be nice if other FreeBSD users
> could benefit as well.

I plain don't like having dozens of directories under a single path.
Your "solution" of moving the stuff from /usr to /usr/packages just move
the problem.

Furthermore, the main advantage you claim is forfeiting the need for the
database of installed files, but having symlinks negates this
disadvantage. Though removal/upgrade of packages could be done by search
ALL symlink directories for invalid symlinks, and this is slow, these
directories of symlinks are a database in themselves, only with
disadvantages.

Another advantage you claim is name clash avoidance. Again, having
symlinks negates this advantage.

It does make it faster to install packages under the current scheme we
use for packages, *BUT*, that is only an artifact of how we do things.
Since either method requires a change in this respect, this isn't really
an advantage.

It does make it easy to "test-upgrade" a package, *IF* you solve the
symlink name clash problem, which you didn't. OTOH, you *CAN*
test-install a port on an alternate directory of your choice, without
any problems. Though this does precludes use of pre-compiled binaries
for this purpose, you'll notice that many people never use pre-compiled
packages at all. They have problems OTHER than PREFIX path.

Also, symlinks make it harder to "eye-ball" things like /usr/local/etc
when searching for problems, as they do not contain all information a
file does (particularly access time and access permissions).

Another big problem is that it would require retraining of personel and
invalidate all existing documentation on our ports systems, and you can
bet *THAT* will make people very pissed off.

And the fact is that name clashes are _not_ a problem for most of us,
and the application database is convenient when using pkg_info to find
out information about a package. If you give it up, for example, you
cannot find out if a file is part of a package or not, as it's presence
in a directory is assumed to mean it is part of that package.

So, you are basically proposing to replace something that exists, works,
whose problems can be fixed without departing from the model, and with
which people are familiar and comfortable with by something which would
require new tools, new ways of doing things, bring new bugs for a while,
introduce new problems and bring no advantage that cannot achieved by
improving the existing method.

The _only_ advantage your method bring is that people who like it like
it. Well, people who don't like it, don't like it. And people who like
the present method like the present method.

So, the way I see it, this proposal brings a new set of problems,
requires us to adjust to a new way of doing things, offers little short
term advantages and no long term ones, and proposes a way of doing
things I plainly don't like, having used it elsewhere.

And, then, there is inertia. You are proposing a huge change in the way
we do things. As long as you are just talking, people who think your
idea is absurd will mostly ignore you. That will change if it gets
closer to adoption.

Most people are HAPPY with the present way of doing things. If you want
to solve name clashes, test-upgrades, faster installs and the like,
there are plenty paths to take within the existing framework, which
would make it much more likely the adoption of the code.

You do whatever you will, but I think the path you are taken is unlikely
to be adopted. I'm not core, I'm not a ports committer, and I'm speaking
only for myself, so feel free to disregard my opinions on this topic.

-- 
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?3A00CC6B.39522CF0>