Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Oct 1999 14:35:50 +0600
From:      Konstantin Chuguev <joy@urc.ac.ru>
To:        Pierre Beyssac <beyssac@enst.fr>
Cc:        Patrick Bihan-Faou <patrick@mindstep.com>, David G Andersen <danderse@cs.utah.edu>, freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG
Subject:   Re: FreeSSH
Message-ID:  <380595E5.B952B4A8@urc.ac.ru>
References:  <199910131428.KAA11701@khavrinen.lcs.mit.edu> <199910131436.IAA02185@faith.cs.utah.edu> <00a801bf158d$421afc20$190aa8c0@local.mindstep.com> <19991013183345.A24019@enst.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
Pierre Beyssac wrote:

> [ -security trimmed from Cc: ]
>
> On Wed, Oct 13, 1999 at 11:11:43AM -0400, Patrick Bihan-Faou wrote:
> > >    pkg_delete lp
> > >    pkg_delete yp
> > >
> > >    Has anyone done/tried this in the past, and if so, what was the
> > > reaction?  Or what do people think?  I realize this sounds a bit like the
> > > "everything is an rpm or dpkg" methodology from Linux, but as long as the
> > > 'base' packages are handled automatically, then it shouldn't impose the
> > > same inconvenience.
> >
> > I think that it would be the next best thing since the package/ports system
> > (as well as a logical step forward). I would love to see most of the things
> > that installed with a "make world" be also registered in the package
> > database. This would make things like upgrading bind, removing sendmail etc
> > a lot easier.
>
> 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.
>
> 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...
>
> To that, you can add several other flaws (broken stable vs unstable
> policy, no /usr/local, many installation scripts asking for
> interactive input...).
>
> 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.
>

Well, what about having just the extended set of makefile variables in
/etc/make.conf?
We already have NOPROFILE, NOPERL, NOSUIDPERL, NOGAMES, NODOC.
I would prefer to have two sets of such variables: one is something like
BUILD_*, another is INSTALL_*;
both for *_LP, *_YP, *_DEVEL, *_PERL etc.
Of course there should be BUILD_ALL and INSTALL_ALL. And of course, some of the
variables would define other ones implicitly.

Then, you will still need to cvs the entire tree (and thus properly
synchronized), but won't need to build or install all the stuff every time. And
you will have just to choose the necessary subset for each your server, router
and/or workstation.

If it is done by making targets like build_* and install_* in the source tree,
then there is an opportunity to make also the uninstall_* targets for removing
unnecessary parts of the distribution.

>
> 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.
>
> 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.
>
> 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.
> --
> Pierre Beyssac          pb@enst.fr
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message

--
        Konstantin V. Chuguev.          System administrator of Southern
        http://www.urc.ac.ru/~joy/      Ural Regional Center of FREEnet,
        mailto:joy@urc.ac.ru            Chelyabinsk, Russia.





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?380595E5.B952B4A8>