[Mageia-dev] Mirror layout, round two

Tue Nov 30 10:46:00 CET 2010

On 30 November 2010 07:29, andre999 <andr55 at laposte.net> wrote:
+> 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 ?
+
+So the user can simply uninstall that extension and update to new
+thunderbird? the user can do this only if he doesn't need that
+extension, only if it doesn't offer features he wants to use. That's
+an invalid argument, if he doesn't need that extension why does he
+have it on his system??
+
+The rationale is/was that mozilla code breaks/broke ABI, so it was
+agreed that extensions are rebuilt for both firefox and thunderbird
+respective new versions.
+
+We will look into that with upstream, so that if a rebuild isn't
+needed, then all the better for us (packagers). But until that
+happens, they will be rebuilt. A 1-2 day delay isn't too much for
+users.
+
+The more pressing issue is, what does this have to do with the topic
+at hand "Mirrors layout, round two" ?? this discussion is deviating
+too much, to the extent it's becoming bloated...
+
+> 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.
+
+Speaking abstractly without examples in this case is just that,
+"speaking". Give us an example of such a case (if any) in a spec file
+so that it can be fixed.
+
+>
+>> 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.
+
+I agree with Michael here, doing sec fixes isn't hard (once one gets
+used to it), just time consuming, and it should be done for all
+packages in the "official" repos; it's true that GPL gives no
+guarantees what so ever, just it's a moral obligation for people
+involved in the FOSS world to support users as best they can.
+
+Users do not differentiate between main/contrib, there's a package
+they install it, I don't think they look from which repo it comes
+from.
+
+>
+>>> 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 ...
+>
+
+Again, give us an example of a spec file that needs "better"
+configuration, otherwise you're theorising.
+
+> 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.
+
+Read above.
+
+>>>
+>>> 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.)
+
+See above (again).
+
+>
+> The essence of our disagreement seems to be how to ensure that core packages
+> are properly supported.
+
+Define "core". For KDE users who want to change GTK themes gtk-chtheme
+(a very small and really old package) is core (i.e. important). The
+point is, a package is offered in the repos it should be as supported
+as possible, main/contrib/non-free doesn't/shouldn't matter.
+
+> 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.
+>
+
+Contrib _is_not_ a sandbox, unless you're implying packagers are using
+users as lab rats.... which isn't true.
+
+> 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é
+>
+
+-- 
+Ahmad Samir
+