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>