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

[Colin Guthrie]

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

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

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

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.

> 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. If we encourage people to enable backports to
get missing packages (this is very distinct and separate from the
unsupported backports).

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

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/]