[Mageia-dev] Mirror layout, round two

[andre999]

Ahmad Samir a écrit :
>
> 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??

You're missing some points here :
1) There is no need to remove an extension.  It will continue to work, 
as long as there hasn't been some error in packaging.  In other words, 
on a generic Mozilla installation, it would continue to work.  The only 
exceptions in the past are when Mozilla changed the version of XML used 
to code extensions.  (Which has happened twice since the beginning of 
Mozilla, if I recall correctly.)  But that would not happen on an update.

2) If by chance the extension does not work properly, it can always be 
updated directly by the update function inside Thunderbird.  Unless the 
distro packaging has somehow disabled this function.  Which would be an 
error in packaging.

3) There is no reason to package Mozilla extensions in the distro, 
except for base localisation modules, which are already in main.

4) If an optional module of any application stops working, that can only 
affect the application in question.  And should not stop the application 
from working.  That does not in itself justify such an extension being 
considered (logically) core.
>
> 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.
See above.
>
> 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.
Good.  Check with upstream.  It can be done quickly, and will help clean 
the system.
By the way, if you install Thunderbird, you can confirm the critical 
elements yourself.  (Installation/update of Extensions and other 
optional modules fully managable from inside Thunderbird.  As well, by 
default there are automatic alerts when updates become available.)
>
> 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...

Everything.
Removing the distinction between core and non-core packages removes an 
important control, useful to give greater assurance that (logically) 
core packages are not broken, thus breaking users' systems.
In my mind, alternative controls are likely to be more complex to 
maintain, and probably less reliable.
It is interesting that the names "core" and "extra" were chosen to 
replace "main" and "contrib".
Especially since "main" was originally meant to be core packages.  But 
not enforced, as some packagers themselves have pointed out.
(One would prefer that I don't mention his name.)
>
>> 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.
More precise details added above.
>
>>> 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 should have said "packages in core", since many such packages aren't 
really logically core to the system.
>
> 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.
I agree that security fixes should be done for all packages in 
"officiel" repos.  (Meaning "core" and "extra".)
But
1) My main point is that priority should be given to truly core 
packages, because, as you mention, it is time consuming.  If core is 
mixed with non-core, that priority is (at least more) difficult to follow.

2) An important part of my proposals has been to remove non-core 
packages from the core repo, to assist in this.
To do that, we have to define clearly what is core and non-core.
(This will have to be done anyway if we wish to give priority to core 
packages.)
I think that this would be a *very* useful discussion in this thread.
And I'm very willing to actively contribute.  (As you might guess:) )
I have to admit, I'm a bit surprised at the opposition to my proposals 
by many (but not all) packagers.
>
> 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.

With this I disagree.  Not only due to my own habit to leave contrib 
disabled most of the time.  And activate it only to find packages not in 
main.  (Often after searching elsewhere - but being a programmer, I'm 
used to compiling/ extra configuring if necessary.)
Many users have expressed on this list a preference to install packages 
from main, rather than contrib.
On the other hand, it is true that many users don't care.
>
>>>> 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.

(Firstly, of course I'm theorising.  And so are those that propose 
eliminating a separate core set of repos.  But you could argue that it 
wasn't clear.)
Sorry, I thought my point was obvious in the context.
If a package is optional, the spec file contents should never block the 
upgrade of the package to which it is an option.
(Which is not necessarily the case if the package is one of several 
required alternatives.)
It might be useful to warn the user that the optional module might not 
work, but to refuse to update the main package just creates an 
unnecessary blockage.
>
>> 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.
I think that this statement stands on its own.
(Note that I said *Mozilla* extension packaging.)
Or read added comments above.
>
>>>> So in sum, this was probably only a packaging problem.  Whatever the
>>>> repository.
In fact, *necessarily* a packaging *error*, to be totally clear.

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

See above (again)
Or think about this.  The thai localisation is "required" in Mandriva. 
Even if one doesn't have any knowledge thai, and thus is totally useless.
Just as logical as an optional Mozilla module blocking the update of 
Thunderbird.
They are both packaging errors.
>
>> 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.

Earlier in this thread, I defined core as necessary for a typical 
desktop or server or development installation.  Adding that certain 
widely useful packages, such as Openoffice/LibreOffice and Firefox could 
be added, due to their general utility.
This was to include complete desktops, such as Gnome, KDE, and LXDE.

By this definition, the old GTK theme would probably not be considered 
core, but that doesn't prevent it from being supported.  I would expect 
that the majority of non-core packages would be well supported.
The fact that the theme is important to the individual user is not key :
The question is more, would problems with it block or significantly 
impair the user's system ?  Considering that there are a number of 
widely used alternatives, it would probably be decided to be non-core.

Which brings up another important point.  Exactly what constitutes core 
and non-core should always be a collective decision.  Meaning that 
borderline cases are never decided by one individual, and decisions 
should follow core guidelines.

In general, this definition of core follows ideas proposed on Mandriva 
cooker recently, although I have long had this view.  I would guess that 
at least a third of "main", if not more, is non-core.

Examples ?  I have installed (and use) poedit and gtranslator, packages 
which facilitate translating .po files.  They came from "main".
In my mind they are non-core, and never should have been in main.
As although they are used in the development process, they are not 
central to it, and no other package would depend on them.
However, collective decisions could say that one of them is core (on the 
basis of being widely used), and I, as a packager, would follow that.

BTW, although I am interested in starting as a new Mageia packager, I 
have decades of programming/development experience, with complex 
systems.  So my comments/suggestions come from considerable experience.
>
>> 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.
Earlier in this thread, it was "main" and "core" that I qualified as 
sandboxes.
In terms of isolating core packages into a repository on which all 
packages could depend.
Obviously, "main" strayed from the concept.

regards

- André