[Mageia-discuss] Package management system

[Michael Scherer]

Le mardi 28 septembre 2010 à 23:16 +0100, Richard a écrit :
> On Tuesday 28 September 2010 22:21:08 Michael Scherer wrote:
> > Le mardi 28 septembre 2010 à 20:20 +0100, Richard a écrit :
> > > How much better could it possibly do this? What am I missing? You have
> > > both mentioned alternatives, some of which I know by name, but in what
> > > way do apt, yum or smart do this job any better?
> >
> > Well, apt is likely to be faster, c++ may be the cause.
> >
> 
> That makes sudden sense; I had forgotten how slow rpmdrake has become while it 
> builds and rebuilds its view of the installed packages inventory. I am 
> guessing this is a "compiled-v-interpreted" thing. No matter how much faster 
> is the PC I use, rpmdrake always seems to be slower than I would like/expect. 
> That, of course, is where urpmi is most certainly your friend being many many 
> times faster to get going - provided I already know the name of what I want 
> to install.

Well, I think the rise of number packages, and the time needed to create
graphical objects are the reason of the slowdown. Maybe there is also a
regression somewhere. But you cannot really compare apt and rpmdrake,
apt being command line only, there is no graphical interface creation
overhead.

> > Smart is portable across type of repository. It also use a cleaner
> > design or algorithm, according to his developer. Among nice features, it
> > can draw graphs of the dependency, feature a command line shell or
> > parallel downloads ( http://labix.org/smart/features )
> >
> A dependency graph would be pretty to look at, but it would be even better if 
> the dependencies were to be colour coded to indicate which are true 
> dependencies and which are just the packager's whim, and then give you the 
> opportunity to ignore those which are neither wanted nor needed.

In rpm, all deps are usually required. You can have Suggests, but
Suggests can be removed without troubles.


> > > I realise that package managers are needed because humans have to add
> > > some intelligence in the form of what libraries are needed to get a
> > > program to run. I also know that sometimes humans get this badly wrong
> > > (try removing a library that you know will never be used and ask yourself
> > > why rpmdrake wants to remove over 200 packages with it!). Do other
> > > package managers manage to avoid this embarassing and frustrating
> > > behaviour? or is it that it is just easier to get it right with package
> > > types other than rpm?
> >
> > Nope, the problem is not linked to rpm or deb. If a library is needed,
> > it is needed, that's simple.
> >
> > A system like emerge or macports ( macports is also in contribs, afaik )
> > may however reduce the required dependency, depending on the software.
> >
> I sense a tendency in your response to the same confusion I am suffering from. 
> On the one hand I find it easy to imagine that the packager is in total 
> control of what a package regards as a "dependency" but on the other hand I 
> must accept that your comment on macports may also be true. I do not know yet 
> how to reconcile these apparent contradictions and I am really hoping I don't 
> have to become the master of package management on all conceivable platforms 
> before I can understand enough of this to make sense of it. 
>
> I can fully grasp the concept that the structure of a package (rpm or deb) is 
> not relevant to the program's requirement for one or more libraries, but I do 
> not understand by what mechanism "nice to haves" are included as "must 
> haves". Is it likely to be simply a packager's oversight or perhaps do some 
> package types not enable the distinction to be made? If the latter, and rpms 
> are of this type, then is ther a package type which does support the 
> distinction?

Macports and emerge are more flexible because they compile packages.

Ie, some packages are inflexible. They requires strict dependency.
For exemple, mplayer requires glibc, and this cannot be changed.

Some have compile time option ( --with, --without at ./configure ).

Mplayer can be compiled without libvorbis support, but you need to
recompile it to enable it if needed later. This is quite annoying for
most users, so usually, the packager have to choose, and in mandriva, we
usually enable this, as most people will prefer features, and those that
have specific requirement are usually able to fix the issue themselves
( or would use another distro like gentoo, we cannot target every
possible use case )

And some have runtime options ( ie a plugins system ). Mplayer is not
like that, but totem ( based on gstreamer ) is. Ie, you can install
totem, and it will not automatically pull every gstreamer plugin to read
every file.    

Packager usually try to split plugin in separate rpms, but then you have
to make a choice, ie do we want the plugin to be installed by default or
not ? It is a packager choice usually.

If you fill there is excessive requirement on a package, feel free to
ask the packager his opinion, or open a bug. But I would recommend that
you first take some time to understand how it work before opening lots
of bugs regarding this .

-- 
Michael Scherer