Date: Tue, 31 Oct 2000 14:18:36 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Patrick Bihan-Faou <patrick@rageagainst.com> Cc: libh@FreeBSD.ORG Subject: Re: BOF at BSDCon: FreeBSD Installer, Packages System Message-ID: <39FE562C.714DBE7C@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Patrick Bihan-Faou wrote: > > > 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. > > Well somebody sent in results that show exactly that... The same person that made the claim. I'll be surprised if he used maximum compression for ZIP, or default compression for gzip (though the later is not to the point, anyway). Of course, if he _does_ confirm he used maximum compression for ZIP, then I will, as I said, be surprised. :-) > > 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. > > Are you so sure that the tar.gz format is the culprit in the installation > slowness ? I build some custom packages using the "pkg_*" tools as they are > today. These packages are really large (30M) since they correspond to a full > (customized) FreeBSD install. Now the slow part is definitely not installing > the content of the package, the really really painfuly slow part is the > cleaning up of the temp directory that holds the uncompressed files. I think > that with a format like ZIP, this is what you are trying to optimize right ? The temporary directory is a by-product of having to decompress everything, and ZIP is a solution to this problem. Or so I understood from jkh's rants. > One way to be fast would be as one suggested the "one directory per package" > approach. It is messy to set-up correctly if you do it manually, but this is > precisely why tools are nice when they exist... I fail to see what it could gain us. > Except that it is not likely to work. At this time, the motto would be more > along the lines "install in /usr/local or you are doomed". This is not > because of a deficiency of the package system, it is simply because most (if > not all) software compiled in will contain the hardcoded "prefix" value > somewhere in the code, and since the default for building the ports is to > have "PREFIX=/usr/local", the resulting package should (must ?) be installed > in /usr/local or it won't work properly. Err... "most (if not all)" is not at all true! That view is seriously biased by the kind of application you run. Anyway, if you need it outside /usr/local, then, yes, you are better installing from ports. But it *will* work correctly from ports, and it will also work correctly for a lot of pre-compiled packages. The whole problem with binary packages is that they screw everyone who is not satisfied with the defaults. It needed not even be mentioned (since Jordan had already done, anyway :). > > 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 . > > Well this is precisely why we need good tools that can handle all of this > automatically. Hell, these things are not really complicated, they are > highly repitive, that's about it. If the situation is not good with AIX or > Solaris, maybe it is because the tools are not good enough on these > platforms. Installing and removing, that's easily automated. Even checking for filename conflict at install. Handling paths all over the place, that's very hard to automate. What's the point of moving to the system most difficult to automate? Unless, of course, you are voluntering to write all these tools before we make the change? > To keep /usr "small" we can use a convention: /usr/package/xyz-version or > something similar to the ports layout (combining the structure of > /var/db/pkg and /usr/ports). > > Also the use of symlinks (can be really hugly) can solve the PATH and > friends issue. > > Maybe it would be time to revisit how these variables are handled (i.e. > created, maintained etc.), maybe a system wide list of prefixes that trigger > the proper instantiation of these variables when needed could be the > solution. Of course then this is not exactly "tradditional" unix any more... Yes, these are all good ideas. <sarcasm>We could also install everything under /usr/local, with application-specific subdirectories only for the applications that need them. Oh, wait, we already do that...</sarcarsm> What people won't suggest for the sake of doing it the hard way! :-) > If you install a pre-compiled package that you obtained from the website, > you DO NOT have a choice: you have to install in /usr/local Granted. > Thinking about it, this little war is even a bit silly. The current port > system is already smart enough to let you use a custom prefix. Why not > implement 2 "standard" profiles: > - "tradditional": default PREFIX=/usr/local > - "split": default PREFIX=/usr/package/$PACKAGE_NAME-$VERSION That's an idea. Of course, it requires more machine, more disk space, and _definitely_ overloads the install cd-roms (or dvds :). If such a suggestion is made with enough people backing "split", it might have a chance, though. > Set the profile you like best in /etc/make.conf, and now everybody is happy. > Of course we also need to develop the smarts that will handle the "split" > layout effectively (i.e. updating the PATH and friends), but this is not > rocket science and a couple of shell or perl scripts can tackle that easily. Easily said than done. > One of the advantages of the "split" version is that binary package installs > can then become really fast no matter what the format of the archive is. Only if we changed the tools to take advantage of the split version. -- 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?39FE562C.714DBE7C>