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

Fri Jun 10 14:51:51 CEST 2011

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
+
+