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é
