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.
>
> > > 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.
> >
> > 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.
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.
>
> > 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.
> >
> > 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.
--
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
http://www.technion.ac.il/~tzafrir
=================================================================
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]
