[Mageia-dev] Missing packages in Mageia 1. How to backport?

[Michael Scherer]

Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit :
> 'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble:
> > Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit :
> >> Hi,
> >>
> >> As I upgrade my various machines (I only really have about 5, so not
> >> that many) I'm running into a few packages that are missing (this is
> >> inevitable).
> >>
> >> Nothing major just little things like trac and supybot etc.
> >>
> >> What is the best way to add these packages to the v1 tree?
> >>
> >> Using backports seems a little odd as this is "unsupported" and we don't
> >> really want to encourage using it as a means to get the missing packages.
> > 
> > If we do not want to have people use backports, we wouldn't have added
> > it in the first place.
> > 
> > I do think backport is perfectly suited for that.
> 
> So the user that just wants to install supybot has to expose themselves
> to the risk of updating to a backported version of gnome or KDE.... this
> is hardly ideal. Especially for novice users.

One alternative would be to make sure that backports for version 1 are
fully supported and break nothing. 

> >> release is obviously frozen so no go there.
> >>
> >> The only real option is updates, but that should obviously have some QA
> >> on it.
> > 
> > Updates is not for new version of software, not for new softwares. And
> > backporting something from cauldron is not a update.
> 
> This seems like a strange statement as */updates on mdv was allowed to
> have new packages in some cases (I've done it before, although I think
> only for * == contrib), so I don't see why we have to restrict this
> possibility in Mageia.

contrib/updates was basically not watched at all. People could send
anything without trouble, and there was no policy ( nor any enforcement
). That's not really the best example to use :)


> >> Perhaps we need to have some kind of exemption to get these missing
> >> packages added?
> >>
> >> Does anyone have any opinions on this?
> > 
> > Yes, I do.
> > 
> > We have used backports in the past for that, and I see no reason to
> > change that.
> 
> This is fine in the regular course of distro evolution, but here we're
> talking about users migrating from Mdv to Mga and finding "stale" Mdv
> packages still installed on their system when they want (and we want to
> provide) a Mageia version. This is very much a special case for this
> transitional period but I feel it's an important one, particularly
> *because* it's the first release.

All releases are equal. And we warned that we would not be able to do
everything, so of course, we will have problem with those that lived on
Mars under a rock, but I think that most people know that we couldn't
have all.

> I think you're thinking in absolute terms rather than transitional
> terms. In absolute terms I agree with you on principle, but I think we
> need to deal with transitional issues gracefully and not treat them as
> second class considerations.

It was not clear for me from your mail that this would be temporary. 

So I assume we can agree to enforce the "new packages go to backports
unless very specific and defined exceptions" policy for version 2 of the
release ? 

If this is temporary, it would be ok, provided we follows the usual
rules about handling updates.

As we do not want to have untested rpms backported in */updates, this
mean that package must be checked by QA before ( and proper testing for
a new rpm is more that just checking it doesn't break ). 

So it should follow the proper policy ( once we agreed on that ).

As discussed in the previous thread, that would for example mean that
the packager that submit the backport is not the one testing it and
giving the go, even if he can test before submitting to avoid wasting QA
time.

Since we want to restrict to package that people have used and missed
for upgrade, I would also add that this part should be checked and
requires :
- a bug report saying "upgrade failed due to that"
- if we want to be inclusive, a forum post could do the trick ( provided
it is in english, or a bug referencing the forum )
- package must be kept upgradable from mandriva 2010.1
- ideally, the upgrade path should be tested, but I am pretty sure that
people will not :).

Finally, I would also add that as soon a package is in updates or
release, the usual rules should apply ( ie, no more exception ). If I
push the package to */updates once getmail because it is missing, but
the next package do not go to */updates unless it fullfill the usual
rules. Any following backports goes to */backports. 

And, just to be clear, the policy only apply to version 1, for x86_64
and i586.

One question would be "what is a pacakge requires a complex backport",
for example, someone yesterday asked for darcs, that requires ghc, that
requires bootstrapping. 

Yes, no ? Why ?

> > If the problem is that backports were too buggy in the past, then we
> > should fix backports process, not bypassing them.
> 
> I don't think this is particularly relevant. Backports are unsupported
> generally. That's a given. 

Before, it was Mandriva that said "we don't support backport", but we
can do thing differently.
 
We do offer them, we spoke of the application made by Stormi to manage
backports request ( among others ), and it was asked to install it on
our servers. So to me, for something unsupported, it seems to be rather
well integrated.

So the question is "what do people mean exactly when they say "backports
are unsupported" and what would it change when compared to updates,
which is supported by definition" ?

Ie, I think we as a community support them to some extend, and so we
should explain what can people expect, and what they cannot.
And if possible, in a positive way ( as one issue we had with backport
was that people kept telling "do not use it", which is why people do not
use it ).

Ie, I have a backport installed, would I receive new version, or not ?
I found a bug, can I fill it in bugs.mageia.org, or not ?
Etc, etc. 


> If we encourage people to enable backports to
> get missing packages (this is very distinct and separate from the
> unsupported backports).

>From the user point of view, any package he doesn't have is a missing
packages, be it due to upgrade from mandriva or because it was not
packaged when he needed :)


> > And if we start by pushing new version in update, people will soon
> > wonder why the new version of X is in updates, while the new version of
> > Y is not, just because we didn't have X in release and Y was there.
> 
> I very much consider "nothing -> version X" quite different from
> "version X -> version Y". I don't think it's a hard concept for anyone
> to grasp.

We kept telling to people that we do not want to place new version in
update, and if we start to do the contrary, this is not really coherent.

So while this can be justified, I think we should take in account
communication with users to clearly explain why we do, and why this is
temporary.

I guess a blog post would do the trick, so would you be volunteer for
that if needed ?

-- 
Michael Scherer