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

Colin Guthrie mageia at colin.guthr.ie
Fri Jun 10 16:46:47 CEST 2011


'Twas brillig, and Michael Scherer at 10/06/11 13:51 did gyre and gimble:
> Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit :
>> 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. 

That's certainly worth considering.

>> 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 :)

Hmm, I can't really disagree with that statement :D

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

Quite. But if the only reason for not providing a particular service or
offering is due to a policy (i.e. people want to provide and others want
to consume) then it's perhaps the policy that need re-evaluating. Just
because it's policy, doesn't mean it's the best solution. Pragmatism
often solves a lot of problems. As I said before I think we can easily
over analyse things...

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

Yeah I'd personally be more than happy with that.

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

That all seems reasonable to me (although I think the QA people can also
be a bit "fast and loose" with some requests (obviously at their own
discretion) - e.g. I doubt they really need to massively test the impact
to other packages of adding something like dd_rescue, more just test
that it "runs OK")

> 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 :).

Yeah I agree to that. I think that while you're right about testing the
upgrade and that it will likely not be fully tested, we can still do a
"what version does mdv 2010.2 have?, what version do we have? Will it
upgrade?" conceptual test (i.e. ask the questions!) which should cover
98.23% of the cases). (made up stat obviously!)


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

Makes sense yes.


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

WFM.

> 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 this kind of thing crops up, I think we can discuss it at the time.
As we will have to go through QA process anyway (albeit fast tracked)
there will have to be some packager<->QA interaction anyway.


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

True...

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

Well we didn't purposefully break backports before either, and of course
some people did look after it nicely. Just because it's not actively
supported doesn't necessarily mean it's not well integrated either. They
are not mutually exclusive.

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

Yes, this makes sense.


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

If required yeah I can write up the outcome of this once the dust has
settled :)

Cheers as always.

Col


-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]


More information about the Mageia-dev mailing list