diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101130/001539.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101130/001539.html | 244 |
1 files changed, 244 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101130/001539.html b/zarb-ml/mageia-dev/20101130/001539.html new file mode 100644 index 000000000..d44993eb3 --- /dev/null +++ b/zarb-ml/mageia-dev/20101130/001539.html @@ -0,0 +1,244 @@ +<!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=%3CAANLkTikRx03UuHgXDXv4myba8d6yMMRT%2BpHUcdbWtkeY%40mail.gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001538.html"> + <LINK REL="Next" HREF="001532.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Ahmad Samir</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3CAANLkTikRx03UuHgXDXv4myba8d6yMMRT%2BpHUcdbWtkeY%40mail.gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">ahmadsamir3891 at gmail.com + </A><BR> + <I>Tue Nov 30 10:46:00 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001538.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001532.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1539">[ date ]</a> + <a href="thread.html#1539">[ thread ]</a> + <a href="subject.html#1539">[ subject ]</a> + <a href="author.html#1539">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On 30 November 2010 07:29, andre999 <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">andr55 at laposte.net</A>> wrote: +><i> Michael Scherer a écrit : +</I>>><i> +</I>>><i> Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit : +</I>>><i> +</I>>>><i> +</I>>>><i> Yann Ciret a écrit : +</I>>>><i> +</I>>>><i> +</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> +</I>>>><i> +</I>>>><i> Unlikely.  This problem is not at all related to separate repositories. +</I>>>><i> +</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> +</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 +</I>><i> extensions installed.  So why should any extension block the update of +</I>><i> Thunderbird ? +</I> +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... + +><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> +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. + +><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> +</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 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. + +><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> +</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> +</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> +Again, give us an example of a spec file that needs "better" +configuration, otherwise you're theorising. + +><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> +</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> +</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> +Read above. + +>>><i> +</I>>>><i> So in sum, this was probably only a packaging problem.  Whatever the +</I>>>><i> repository. +</I>>>><i> +</I>>><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> +</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> +See above (again). + +><i> +</I>><i> The essence of our disagreement seems to be how to ensure that core packages +</I>><i> are properly supported. +</I> +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. + +><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> +Contrib _is_not_ a sandbox, unless you're implying packagers are using +users as lab rats.... which isn't true. + +><i> Your focus is removing 1 of these repository sets, and thus the sandbox. +</I>><i> But I don't see your solution for giving priority to maintaining core +</I>><i> packages ? +</I>><i> These factors are undeniably linked. +</I>><i> +</I>><i> By the way, I'm very willing to be convinced.  Just give me the logic. +</I>><i> +</I>><i> regards +</I>><i> +</I>><i> - André +</I>><i> +</I> +-- +Ahmad Samir +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001538.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001532.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1539">[ date ]</a> + <a href="thread.html#1539">[ thread ]</a> + <a href="subject.html#1539">[ subject ]</a> + <a href="author.html#1539">[ 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> |