From owner-freebsd-current Thu Oct 14 3:20:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (Postfix) with ESMTP id 036A714C97; Thu, 14 Oct 1999 03:20:29 -0700 (PDT) (envelope-from kooij@pc47.mpn.cp.philips.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id MAA01958; Thu, 14 Oct 1999 12:20:28 +0200 (MEST) (envelope-from kooij@pc47.mpn.cp.philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma001953; Thu, 14 Oct 99 12:20:28 +0200 Received: from pc47.mpn.cp.philips.com (pc47.mpn.cp.philips.com [130.139.64.47]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA13695; Thu, 14 Oct 1999 12:20:27 +0200 (MET DST) Received: from localhost [127.0.0.1] (kooij) by pc47.mpn.cp.philips.com with esmtp (Exim 3.03 #1 (Debian)) id 11bhzm-0002q7-00; Thu, 14 Oct 1999 12:20:26 +0200 Date: Thu, 14 Oct 1999 12:20:26 +0200 (CEST) From: Joost Kooij To: Pierre Beyssac Cc: Patrick Bihan-Faou , David G Andersen , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, jos@hal.mpn.cp.philips.com, Joost van Baal Subject: Debian (was: FreeSSH) In-Reply-To: <19991013183345.A24019@enst.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On Wed, 13 Oct 1999, Pierre Beyssac wrote: > There are a _lot_ of pitfalls to this kind of approach, as I have > discovered using Linux Debian. This would probably open a can of > worms you have no idea of. IMHO, the single biggest mistake in > Debian is the all-encompassing package system which can make your > life miserable in no time. IMHO this highly depends on your point of view. If you want to to stay in absolute control (and assume all responsibilities for the smooth cooperation for the different parts of your systems), then yes, I agree that the "glue" that Debian adds gets in your way a lot of the time. > I have found this the hard way, because I have to administer a > network of Debian PCs. Any attempt to upgrade something, even a > minor application, rapidly turns into a dependency nigthmare forcing > you to update half of your system. This is made even worse by > endless changes in the glibc, itself included in the package system: > since you can code that dependency in the package system, many > packages require such and such version of the glibc. In turn, > frequent incompatible updates of the glibc are made by the developpers > with the excuse that it's all handled by the package system anyway... Please let's get the terms of this discussion clear first. You are running "stable" Debian aren't you? Debian puts in a lot of effort to make upgrades from one version of "stable" to the next version of "stable" as smooth as possible. If you use tools like apt-get and dselect, this should in practice be painless and mostly flawless. As ever, RTFM and YMMV accordingly. Sometimes people insist on using the dpkg backend in the wrong situations, like when upgrading a whole slew of packages at once. Many times this arises from not understanding or not appreciating tools like dselect and apt-get. Anyway, the bottom line is: keep with "stable" and any signs of dependency problems usually indicate that you are doing something wrong, not Debian. > To that, you can add several other flaws (broken stable vs unstable > policy, no /usr/local, many installation scripts asking for > interactive input...). 1. Debian is very slow to release new "stable" versions. This can be called a "broken release policy", not a "broken stable vs unstable policy". That is a big difference. 2. There is actually a /usr/local. It is reserved to the local admin. No Debian package shall touch what the local admin puts in /usr/local. From Debian's point of view, this makes a lot of sense. To consider this broken is to consider Debian's goals broken. There's little sense in argueing about this IMHO. 3. Installation scripts asking questions is intimately related to the strive to have packages really configuring themselves to be "ready to run" upon installation. In many cases, Debian actually does a fine job here. The problem is now, that Debian is so big and there are a lot of questions asked. There is some work being done, making it possible for packages to ask the questions before or after installation. Still, trying to configure packages means requiring user input at some stage. Again, this is a design goals issue. > The bottom line is: I'm much happier with FreeBSD's use of > distributions for the base system than with a Debian-style package > system. Great. Use whatever works best for you. If you find yourself forced (by the suits of course, because Linux is hype) to work with Debian, here's some tips to make things easier for you: - Stay with "stable". Especially if you're managing a whole network of machines and "reproducible" is a key value to your operation. - Build local versions of packages if stable can't satisfy your needs. This is actually remarkably easy with newer versions[1] of the apt-get tool: apt-get source somepackage fetches and unpacks sources for a package. Then make your mods/patches and type[2]: debian/rules binary in the top-level source directory. You now have a localized version of the package that you can install manually with dpkg. Don't forget to put the package on hold[3], if you want to stop it from being upgraded automatically. [1] If this doesn't work for you, you can always get the .orig.tar.gz, diff.gz and .dsc files by hand and use "dpkg-source -x *.dsc" to achieve the same result. [2] Actually, it's better to type "fakeroot debian/rules binary". Tar needs to create and archive with files owned by root. Fakeroot (from the fakeroot package) tricks tar into thinking you're root when you're not, thus allowing a normal user to build the .deb. [3] echo "hold" | dpkg --set-selections "somepackage" or use dselect. - Use the Debian Bug Tracking system (http://bugs.debian.org) > That is no to say there can be no good package system, but we have > to think twice before we implement anything like that, first and > foremost dependencies on system libraries. I agree again. This sort of decision is made at a very deep level and relates to fundamental design goals. > And, IMHO, package handling for general-purpose applications and > package handling for the core system are a very different problem > and should be handled in very different ways. In this respect, the differences between Debian and FreeBSD are quite revealing: Debian draws the line between kernel- and user-space and completely delegates the former, working on integration of the latter. FreeBSD draws the line at a point in userspace and delegates the user-space-only part, concentrating on the other part. Considering the above, the Debian packaging system may not be the optimal solution to FreeBSD's needs (whatever those may be.) Conversely, FreeBSD's great cvs-based system that allows things like "cvsup" and "make world" are very hard to transpose on Debian as it is. > The Solaris way, while far from perfect, is at least usable for > the most past to handle choice at installation and (not too frequent) > evolutions of system components. Please pass me too that tube of glue you're sniffing. Maybe that'll help me to better reconciliate with default Solaris. Cheers, Joost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message