[Mageia-dev] Mirror layout, round two

Tue Nov 30 06:29:17 CET 2010

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