diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101201/001576.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101201/001576.html | 349 |
1 files changed, 349 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101201/001576.html b/zarb-ml/mageia-dev/20101201/001576.html new file mode 100644 index 000000000..105805d84 --- /dev/null +++ b/zarb-ml/mageia-dev/20101201/001576.html @@ -0,0 +1,349 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF6B618.907%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001575.html"> + <LINK REL="Next" HREF="001577.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF6B618.907%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Wed Dec 1 21:54:48 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001575.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001577.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1576">[ date ]</a> + <a href="thread.html#1576">[ thread ]</a> + <a href="subject.html#1576">[ subject ]</a> + <a href="author.html#1576">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Ahmad Samir a écrit : +><i> +</I>><i> On 30 November 2010 07:29, andre999<<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">andr55 at laposte.net</A>> wrote: +</I>>><i> Michael Scherer a écrit : +</I>>>><i> +</I>>>><i> Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit : +</I>>>><i> +</I>>>>><i> Yann Ciret a écrit : +</I>>>>><i> +</I>>>>>><i> I dislike the main/contrib separation in some case. +</I>>>>>><i> The first example is with Mozilla Thunderbird packages. Some extension +</I>>>>>><i> packages are in contrib. So each time thunderbird received security +</I>>>>>><i> update, the update cannot be installed because of non automatically +</I>>>>>><i> rebuild of his contrib package. And each time I see a bug report of user +</I>>>>>><i> asking a manual rebuilt. With only one core media, this situation will +</I>>>>>><i> disapear (I hope). +</I>>>>><i> +</I>>>>><i> Unlikely. This problem is not at all related to separate repositories. +</I>>>><i> +</I>>>><i> It is. It is exactly related to the fact that thunderbird is supported, +</I>>>><i> and that extension are not despites depending on it. +</I>>><i> +</I>>><i> In this case it is evident that you don't understand how extensions work +</I>>><i> with mozilla products. +</I>>><i> Thunderbird will function correctly with no extensions installed. +</I>>><i> So why should any extension block the update of Thunderbird ? +</I>><i> +</I>><i> So the user can simply uninstall that extension and update to new +</I>><i> thunderbird? the user can do this only if he doesn't need that +</I>><i> extension, only if it doesn't offer features he wants to use. That's +</I>><i> an invalid argument, if he doesn't need that extension why does he +</I>><i> have it on his system?? +</I> +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. +><i> +</I>><i> The rationale is/was that mozilla code breaks/broke ABI, so it was +</I>><i> agreed that extensions are rebuilt for both firefox and thunderbird +</I>><i> respective new versions. +</I>See above. +><i> +</I>><i> We will look into that with upstream, so that if a rebuild isn't +</I>><i> needed, then all the better for us (packagers). But until that +</I>><i> happens, they will be rebuilt. A 1-2 day delay isn't too much for +</I>><i> users. +</I>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.) +><i> +</I>><i> The more pressing issue is, what does this have to do with the topic +</I>><i> at hand "Mirrors layout, round two" ?? this discussion is deviating +</I>><i> too much, to the extent it's becoming bloated... +</I> +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.) +><i> +</I>>><i> Additionally, modules installed will continue to work as long as the major +</I>>><i> version doesn't change. (Actually slightly more complicated.) +</I>>><i> In some cases one won't be able to newly install a module because a config +</I>>><i> file inside the module - equivalent to the spec file in rpm packages - +</I>>><i> hasn't been updated for compatible versions. (In fact, the versions were +</I>>><i> probably improperly specified.) But installed modules will continue to +</I>>><i> function. +</I>>><i> It is possible that the packager did not realise this - or for whatever +</I>>><i> reason did not properly set up a spec file - but this issue has nothing at +</I>>><i> all to do with separate sets of repositories. +</I>><i> +</I>><i> Speaking abstractly without examples in this case is just that, +</I>><i> "speaking". Give us an example of such a case (if any) in a spec file +</I>><i> so that it can be fixed. +</I>More precise details added above. +><i> +</I>>>><i> That precisely because we tell "security and bugfixes occurs only on +</I>>>><i> main" that contribs got broken, since the security team do not care to +</I>>>><i> not break contribs packages +</I>>><i> +</I>>><i> The crux of this problem is that core (in the general sense) packages are +</I>>><i> dependant on packages that are not recognized as core. +</I>>><i> That again has nothing to do with repositories as such. +</I>I should have said "packages in core", since many such packages aren't +really logically core to the system. +><i> +</I>><i> I agree with Michael here, doing sec fixes isn't hard (once one gets +</I>><i> used to it), just time consuming, and it should be done for all +</I>><i> packages in the "official" repos; it's true that GPL gives no +</I>><i> guarantees what so ever, just it's a moral obligation for people +</I>><i> involved in the FOSS world to support users as best they can. +</I>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. +><i> +</I>><i> Users do not differentiate between main/contrib, there's a package +</I>><i> they install it, I don't think they look from which repo it comes +</I>><i> from. +</I> +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. +><i> +</I>>>>><i> Rather that one package was updated, and an optional installed module +</I>>>>><i> was not. +</I>>>>><i> The fact that the module is optional is the key point. +</I>>>>><i> The installer should be flexible enough to give a warning in this case, +</I>>>>><i> and ask if you wish to continue the installation. +</I>>>><i> +</I>>>><i> So basically, you want a --nodeps ? +</I>>>><i> If there is a requires, there is usually a good reason. Engineering is +</I>>>><i> not randomly adding line to a file until it work. +</I>>><i> +</I>>><i> How about better configured spec files ? +</I>>><i> A better definition (in general) of core packages ? +</I>>><i> A focus on ensuring that core packages are maintained ? +</I>>><i> Basically my idea behind a core sandbox. +</I>>><i> But if you have a better idea ... +</I>><i> +</I>><i> Again, give us an example of a spec file that needs "better" +</I>><i> configuration, otherwise you're theorising. +</I> +(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. +><i> +</I>>><i> Just remember, eliminating a supported core breaks the sandbox. +</I>>><i> So removing repositories does have secondary effects. +</I>>><i> And they should be seriously considered and discussed by those proposing to +</I>>><i> remove the repositories. +</I>>><i> +</I>>>>><i> As well, in the case of Thunderbird, it is almost certain that the +</I>>>>><i> installed module was in fact compatible with newer version of +</I>>>>><i> Thunderbird. (A security problem may directly impact Thunderbird or the +</I>>>>><i> module, but highly unlikely both packages.) +</I>>>>><i> Rpm tags should have been set so that Thunderbird would recognize that +</I>>>>><i> the module was appropriate in the newer version. +</I>>>><i> +</I>>>><i> No. If there is stricter dependency, it is precisely because there is no +</I>>>><i> guarantee of any kind of ABI between thunderbird versions. The same goes +</I>>>><i> for firefox. +</I>>><i> +</I>>><i> Overly restrictive compatibility specification is a very a common error in +</I>>><i> Mozilla extension packaging. (It's mentioned in their development guides.) +</I>>><i> But the rpm packager should be knowledgable enough to recognize it. +</I>>><i> But such errors do happen. +</I>><i> +</I>><i> Read above. +</I>I think that this statement stands on its own. +(Note that I said *Mozilla* extension packaging.) +Or read added comments above. +><i> +</I>>>>><i> So in sum, this was probably only a packaging problem. Whatever the +</I>>>>><i> repository. +</I>In fact, *necessarily* a packaging *error*, to be totally clear. + +>>><i> +</I>>>><i> No. Not at all. +</I>>>><i> The problem is linked to the difference of support between main and +</I>>>><i> contribs. +</I>>><i> +</I>>><i> In this case, it is inappropriate packaging. +</I>>><i> Other cases could be a difference of support. +</I>>><i> +</I>>><i> There is no reason that extensions should ever block the upgrade of +</I>>><i> Thunderbird, unless when one passes from one major version to another. +</I>>><i> In that case, the extension will have to be rewritten, a development +</I>>><i> function. +</I>>><i> (That has only happened a few times since the beginning of Mozilla.) +</I>><i> +</I>><i> See above (again). +</I> +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. +><i> +</I>>><i> The essence of our disagreement seems to be how to ensure that core packages +</I>>><i> are properly supported. +</I>><i> +</I>><i> Define "core". For KDE users who want to change GTK themes gtk-chtheme +</I>><i> (a very small and really old package) is core (i.e. important). The +</I>><i> point is, a package is offered in the repos it should be as supported +</I>><i> as possible, main/contrib/non-free doesn't/shouldn't matter. +</I> +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. +><i> +</I>>><i> My point is that a sandbox will facilitate proper support. Which would be +</I>>><i> facilitated by keeping the 2 sets of free repositories. And restricting +</I>>><i> what should be considered core. +</I>>><i> We both know that Mandriva is moving in that direction. Evidently +</I>>><i> recognising that they weren't restrictive enough in the past. +</I>><i> +</I>><i> Contrib _is_not_ a sandbox, unless you're implying packagers are using +</I>><i> users as lab rats.... which isn't true. +</I>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é + + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001575.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001577.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1576">[ date ]</a> + <a href="thread.html#1576">[ thread ]</a> + <a href="subject.html#1576">[ subject ]</a> + <a href="author.html#1576">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |