[Mageia-dev] Mirror layout, round two

[Ahmad Samir]

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