[Mageia-dev] Mirror layout, round two

[andre999]

Michael Scherer a écrit :
> Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit :
>    
>> Yann Ciret a écrit :
>>
>>      
>>> I dislike the main/contrib separation in some case.
>>> The first example is with Mozilla Thunderbird packages. Some extension
>>> packages are in contrib. So each time thunderbird received security
>>> update, the update cannot be installed because of non automatically
>>> rebuild of his contrib package. And each time I see a bug report of user
>>> asking a manual rebuilt. With only one core media, this situation will
>>> disapear (I hope).
>>>
>>>        
>> Unlikely.  This problem is not at all related to separate repositories.
>>      
> It is. It is exactly related to the fact that thunderbird is supported,
> and that extension are not despites depending on it.
>    
In this case it is evident that you don't understand how extensions work 
with mozilla products.  Thunderbird will function correctly with no 
extensions installed.  So why should any extension block the update of 
Thunderbird ?
Additionally, modules installed will continue to work as long as the 
major version doesn't change.  (Actually slightly more complicated.)
In some cases one won't be able to newly install a module because a 
config file inside the module - equivalent to the spec file in rpm 
packages - hasn't been updated for compatible versions.  (In fact, the 
versions were probably improperly specified.)  But installed modules 
will continue to function.
It is possible that the packager did not realise this - or for whatever 
reason did not properly set up a spec file - but this issue has nothing 
at all to do with separate sets of repositories.

> That precisely because we tell "security and bugfixes occurs only on
> main" that contribs got broken, since the security team do not care to
> not break contribs packages.
>    
The crux of this problem is that core (in the general sense) packages 
are dependant on packages that are not recognized as core.
That again has nothing to do with repositories as such.

>> Rather that one package was updated, and an optional installed module
>> was not.
>> The fact that the module is optional is the key point.
>> The installer should be flexible enough to give a warning in this case,
>> and ask if you wish to continue the installation.
>>      
> So basically, you want a --nodeps ?
> If there is a requires, there is usually a good reason. Engineering is
> not randomly adding line to a file until it work.
>    
How about better configured spec files ?
A better definition (in general) of core packages ?
A focus on ensuring that core packages are maintained ?
Basically my idea behind a core sandbox.
But if you have a better idea ...

Just remember, eliminating a supported core breaks the sandbox.
So removing repositories does have secondary effects.
And they should be seriously considered and discussed by those proposing 
to remove the repositories.

>> As well, in the case of Thunderbird, it is almost certain that the
>> installed module was in fact compatible with newer version of
>> Thunderbird.  (A security problem may directly impact Thunderbird or the
>> module, but highly unlikely both packages.)
>> Rpm tags should have been set so that Thunderbird would recognize that
>> the module was appropriate in the newer version.
>>      
> No. If there is stricter dependency, it is precisely because there is no
> guarantee of any kind of ABI between thunderbird versions. The same goes
> for firefox.
>    
Overly restrictive compatibility specification is a very a common error 
in Mozilla extension packaging.  (It's mentioned in their development 
guides.)
But the rpm packager should be knowledgable enough to recognize it.
But such errors do happen.
>> So in sum, this was probably only a packaging problem.  Whatever the
>> repository.
>>      
> No. Not at all.
> The problem is linked to the difference of support between main and
> contribs.
>    

In this case, it is inappropriate packaging.
Other cases could be a difference of support.

There is no reason that extensions should ever block the upgrade of 
Thunderbird, unless when one passes from one major version to another.
In that case, the extension will have to be rewritten, a development 
function.
(That has only happened a few times since the beginning of Mozilla.)

The essence of our disagreement seems to be how to ensure that core 
packages are properly supported.
My point is that a sandbox will facilitate proper support.  Which would 
be facilitated by keeping the 2 sets of free repositories.  And 
restricting what should be considered core.
We both know that Mandriva is moving in that direction.  Evidently 
recognising that they weren't restrictive enough in the past.

Your focus is removing 1 of these repository sets, and thus the sandbox.
But I don't see your solution for giving priority to maintaining core 
packages ?
These factors are undeniably linked.

By the way, I'm very willing to be convinced.  Just give me the logic.

regards

- André