Ahmad Samir a écrit :
On 30 November 2010 07:29, andre999<and...@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é
