On Tuesday 20 August 2002 15:52, Tzafrir Cohen wrote:
> On Tue, 20 Aug 2002, Meir Kriheli wrote:
> > > > 1. Control of dependenices. With binary distros you're bound to the
> > > > dependencies as decided by the package maintainer. Let's for example
> > > > take vim in Debian. If you install vim lipgpm will be installed as
> > > > well. I hate gpm and never use it, don't want the stuff on my
> > > > system.With Debian you have no choice. With Gentoo you can set
> > > > USE="-gpm" before buliding the package. If you hate QTyou can add -qt
> > > > to your use flags and no optional qt interfaces to packages will
> > > > becompiled.Same goes from gtk, gnome or whatever. For a list and
> > > > usage of USE flags see:
> > > > http://gentoo.org/doc/use-howto.html
> > >
> > > fine.
> > >
> > > in the case of debian, you simply need to do the minimal editing of the
> > > control files. In case of RPM files:you need to edit the rpm spec.
> > >
> > > Normally I don't want to care about such things. But when I want to
> > > care, it is not a problem to control them. Not a hassle, either.
> >
> > With Gentoo it is a lot easier and no need to learn package file specs.
> > Just set and ENV var and emerge.
> >
> > And I do care about such things.
>
> That is what I thought first. But later noticed I don't have the time for
> that. Not after installing a number of machines. I generally know where
> the distro got it wrong.
>
> I may find out where the distro has got it wrong (or where I got it wrog)
> later on, and rebuild the package.
Debian is constatly falling behind and can't keep up with new software
releases (not to mention months of freeze time when unstable is stopped from
being updated as well). this is not a bad thing by itself, but usually when
someone runs unstable they do it because they want the latest and greatest.
Now that there are unoffical kde-3 packages, where are the rest of the
distro's support. For example: there's and licq 1.2.0a release, and is in
unstable. Try installing it wih kde pure environemnt, no luck. It is built
against qt2. No qt3 plugin and no kde plugin supprt (which allows docking) in
site. Those are the little things that make a distro polished. With Gentoo it
is not a problem, and it uses a SLOT mechanism which allows different
versions/releaseses of packages to be used at the same time and makes sure
software is built against the correct one.
> > > > 2. Control of packages. You can easily change and add your own
> > > > ebuilds (package descriptions), while the creation of rpms and debs
> > > > is more involved and cubersome. With moderate bash scripting
> > > > knownledge you can create your own packages for obscure apps or
> > > > modify extisting ebuilds.
>
> There are relatively very few programs not in debian's repository, or not
> in redhat/mandrake (if you include the contribs, that normally give you a
> resonably sane package. Not always, though)
>
> If not, you grab the source package of a similar package and modify it.
> Doesn't take a genious. Doesn't take much work.
>
> BTW: do you trust the install procedure of the original packages? I have
> learned not to.
It is not the you do it all the time. But when you need it the power is
unleashed easily.
You don't need to trust a pakages install process. See below.
> > > If you want to shoot yourself in the foot, install from tarballs. Fine
> > > by me. There are a number of wrapper systems for installing from
> > > tarballs under /usr/local . But this is not what you want: you want
> > > files that will be part of one distribution.
> >
> > Why installing from tarballs is considered shooting yourself in the foot
> > ? After all we are talking about Open Source, not openbinaries. Linux
> > users should have no problems installing source packages. And you're not
> > installing directly, emerge and portage take care of it for you, and
> > tracks everything installed (which can be removed later).
>
> Unless there is a conflict over some files. Or files modified during the
> install script.
>
> A silly install script may run:
>
> mv ${CONFIG_FILE} ${CONFIG_FILE}.${UNIQUE_EXTN}
> cp something ${CONFIG_FILE}
>
> and then, on uninstall time:
>
> mv ${CONFIG_FILE}.${UNIQUE_EXTN} ${CONFIG_FILE}
>
> Whatever wrapper that you put around this, may interact badly with
> anything else that may edit ${CONFIG_FILE}. Hence the need for a notion of
> a config file, and the need to mark some files as config files.
Package management is not that are and i handled even on LFS systems with
quite an ease.
Seems like you never used Gentoo at all, and talking on from theory of how you
think it works, and this is bad. You should at least give it a try for a week
or two before you assume things or pass judgment.
For config files, gentoo uses CONFIG_PROTECT and CONFIG_PROTECT_MASK vars,
when dir are set in CONFIG_PROTECT (/etc for example as is the default with
some other dirs) no script can overwrite a file in that dir, and newly config
files are stored in alternate names.
When a package is emerged, it is compiled and installed on temporary work
dirs. The process is sandbox (with LD_PRELOADed lib which intercepts disk
access) and cannot write outside that dir. Package prefixes are modified to
install to the temporary dir. After the installation process to the sandboxed
dir is completed, the files are registered and copied to the correct place
(but not overwriting CONFIG_PROTECTed dirs). You don't rely on make install
and that's it.
> And if the package needs to add menu items? (yup, on mandrake and debian
> even twm has a complete menu of all the programs)
>
> And if this is a daemon: should it be started automaticaly? Should an
> upgrade of it restart it?
>
> Those are some examples of why package management is not so simple. It is
> more than simply packing and installing a package: it is about how the
> package interacts with the rest of the system.
>
Before/after the package is installed the ebuild can perform additional
operations like installing a menu file, restarting the daemon or what ever
(and many ebuilds do that).
> > > FWIW, I have installed manyprograms on my Mandrake workstation. All of
> > > them were RPMs. Packed by me, if necessary. In most cases it wasn't
> > > necessary.
> > >
> > > The debian project has many developers, working with very loose
> > > cooperation. They had to define strict interfaces between the different
> > > packages, or else it will be a mess.
> >
> > Fine by them, but I want my distro to work by my rules. One of the things
> > that I hate is that Debian throws everything into /usr/bin. Now try to
> > change that and adjust other packages as well. On gentoo all kde related
> > ebuilds inherit from kde's eclass one change and off you go.
>
> How exactly do you define a package as "kde-related"?
>
> rpm can install a package under a different prefix, but I believe that
> some of the scripts (e.g: the X sessions ascripts) have the prefix '/usr'
> hardwired. I am also not aware of any way to do this methodically.
>
A package can be kde related when it has optional KDE interfaces (like licq
mentioned above with qt-plugins) or koffice (which is still compiled agains
qt2/kde2 btw).
With Gentoo usually dirs are not hardwired. Xsession for example usualy
sources the file for the targeted DE/WM. That way Gentoo can handle several
version of DE (e.g. having kde 2.2.2 and 3.0.3 and cvs at the same time
installed in different dirs).
> > > Frankly, I can't blame any distro for not having KDE3 so far. KDE3.0.2
> > > has had quite a few desktop crashes (not mere application crashes).
> > > Currently KDE2 is the "stable" KDE, whereas KDE3 is still the "bleeding
> > > edge". I figure that it will be the same way until 3.1 or so.
> > > (I know bidi is a killer feature for us, but this about the rest of the
> > > world for a moment)
> > >
> > > The same applies for gnome2.
> >
> > This is wrong. I'm using KDE3 since 3.0 has started from cvs in and since
> > 3.0 beta I don't see any special crashes. I'm running 3.1alpha1 now (and
> > cvs, they are all part of Gentoo's portage, and tracked by the system). I
> > think you should blame your distro's packagers instead of KDE.
> >
> > I rememebr when Debian uses to track kde's 2.2 betas in unstavle when
> > krusty was the maintainer, no one said: Hey don't put that it in it is
> > bleeding edge.
>
> KDE2.0 was not as stable as KDE2.1 and 2.2.
So what ? If I'm tracking unstable I want unstable and latest software, this
point is moot. It's like saying Mandrake won't package kde 3.0.3 in cooker
(or redhat in rawhide) because it is not considered stable.
--
Meir Kriheli
MKsoft systems
http://www.mksoft.co.il
================================================================To unsubscribe, send
mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
