Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Paul de Vrieze]

On Saturday 20 May 2006 18:00, Alec Warner wrote:
> Paul de Vrieze wrote:
> > The promissed glep on package manager requirements. Please comment on it.
> > There are some parts that may be controversial (portage has in the past
> > not provided support for reverting to stable either), but please keep the
> > discussion on topic.
> >
> > Paul
>
> s/primary/official/g
>
> This primary business is silly IMHO.  GCC is Gentoo's official compiler,
>   baselayout is the "official" init system, etc...

There might be multiple official package manager. Only one has the lead 
position from a gentoo point of view. Please also be aware that the term 
primary is from the point of view of gentoo, not from user point of view. 
This GLEP does not mean that there can not be multiple package managers that 
could play the role of primary package manager for a system.

>
> There is precedent here, and you are ignoring it.
>
> Basically this whole GLEP is a reactive farse.  I realize thats not your
> intention, you seriously want a defined manner in which many package
> managers can live.  However reading the GLEP it seems to be built
> completely against Paludis; stacking the deck as it were.  However I
> left other comments below ;)

I am not against paludis at all. I want to set the playing field on which 
alternate package managers can thrive. This way there would be a way in which 
package managers can live along eachother and better gentoo. I realise this 
should have been written earlier, preventing wasted efforts, and I am sorry I 
did not do it before.

On design quality I'd like to say that design quality is not only formed by 
how well the design is on itself. It is even much more how well a system fits 
in its environment. Ignoring what is already there is the easy way out. A way 
in which a transition can be made without breaking what is there, and still 
ensuring a good design after the transition. That is really great design.

I'll react on your comments below.

> >
> > Not a problem for this GLEP. There is no previous standard as the issue
> > did not exist before. This GLEP is to prevent future compatibility
> > issues.
>
> If there is Official and 'everything else" I think this whole section
> can be dropped.

The thing is that there are possibilities in between them. They might not be 
used, but we owe it to current and future package manager designers to allow 
this possibility. A secondary package manager that installs rpm packages 
(perhaps for LSB compatibility) can very well be official, but not even able 
to set the standard on packages (hell it uses rpm's).

<cut>
> > As a package manager is in a state of higher support there are higher
> > requirements to it. The purpose of these requirements is to ensure the
> > unity of the distribution and the package tree. For this purpose it is
> > needed that there is only one primary package manager.
>
> One official package manager, but many can be used.

Certainly true. I've added something to this extend to the next revision.

>
> >     primary package manager requirements <#id13>
> >
> > The primary package manager is the package manager that sets the
> > standards for the tree. All ebuilds in the tree must function with the
> > primary package manager. As the primary package manager sets the
> > standard it does not have to maintain compatibility with other package
> > managers.
>
> This outlook inhibits innovation in the tree.  I agree with stephen, in
> that the tree should set the standard.  If you want a new feature in the
> tree, I think a proposal would be good ( not a GLEP necessarily, but a
> tree proposal ).  I think crap goes in that is not discussed in advance...
>
> One could say, the official package manager sets the standard such that
> someone needs to have support in the package manager for it to operate
> properly.

Look at this way. It is only a standard when it is supported in a testing 
version of the primary package manager.

> However in many industries you find the opposite.  First a standard is
> set, then a prototype (reference board, whathaveyou) is created, then it
>   is released for companies to use.  Here you want the opposite.  The
> feature as an idea is created, portage implements it, then the other
> package managers copy it?  Sounds silly ;)

Package managers may implement anything they want. Packages (not package 
managers) may only use it when the primary package manager supports it. I 
have got clarified it in the new revision that not only the implementation 
determines the standard, but also the existing guidelines, qa tools, etc. As 
example paludis would be perfectly right in not supporting all kinds of 
toplevel magic. Even though portage will not complain it is accepted as 
something that must not be done.

>
> > The primary package manager does however have the responsibility that it
> > must be very stable. The primary package manager must maintain
> > compatibility with old versions of itself for extended periods of time.
> > This compatibilty time is set by the council. The suggested time would
> > be one year from the point that there is a compatible stable version for
> > all supported architectures.
>
> To be honest even portage never did this.  We waited "as long as we felt
> necessary" and then broke compat.

You are probably right. Maybe the time period is too long. I added the period 
as indication, In principle I am open for any change in the periods. A glep 
without filled in periods is kind of silly though.

I don't think that this GLEP should avoid setting the standard for portage in 
the future. As stated in the motivation, I agree with many others that 
portage is up for replacement.

> > The primary package manager is maintained on official gentoo
> > infrastructure, under control of gentoo developers.
>
> This has no reasoning behind it, in my eyes.

It shows how important the package manager is to gentoo. The package manager 
determines the features of gentoo and the perception by users.

> > Fourth, there must be support. This means that the package manager is
> > actively maintained under control of gentoo. If it is not maintained on
> > gentoo infrastructure, the means must be there to move the package
> > manager, with its change history, to gentoo infrastructure. This means
> > that it must be maintained on a gentoo supported versioning system, or
> > on a version system whose history can be converted to a gentoo supported
> > versioning system.
>
> Again I don't see a reason for it to be on Gentoo infra, or even for it
> to be managed by Gentoo developers offsite.  As long as it's active.
> One could say Portage is a bit dormant, sure bugs get fixed
> features...take a while, as many people will note :)

I don't want to argue with you about portage quality as I agree that portage 
has these deficiencies. Portage is however not a candidate primary package 
manager, but a primary package manager. This means that it is likely that 
portage will be replaced by another package managers.

While the GLEP does not say anything about it, I do think it is likely that 
once a new package manager has been chosen as primary package manager, that 
the previous package manager does not even qualify as secondary package 
manager.

One of the things that I expect the council to take into account in deciding 
wether a package manager will replace the current primary package manager is 
its additional features.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net