diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/005346.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/005346.html | 301 |
1 files changed, 301 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/005346.html b/zarb-ml/mageia-dev/2011-June/005346.html new file mode 100644 index 000000000..cc688343d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005346.html @@ -0,0 +1,301 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Missing packages in Mageia 1. How to backport? + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Missing%20packages%20in%20Mageia%201.%20How%20to%20backport%3F&In-Reply-To=%3C1307710311.26948.154.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005332.html"> + <LINK REL="Next" HREF="005364.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Missing packages in Mageia 1. How to backport?</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Missing%20packages%20in%20Mageia%201.%20How%20to%20backport%3F&In-Reply-To=%3C1307710311.26948.154.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Missing packages in Mageia 1. How to backport?">misc at zarb.org + </A><BR> + <I>Fri Jun 10 14:51:51 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005332.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? +</A></li> + <LI>Next message: <A HREF="005364.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5346">[ date ]</a> + <a href="thread.html#5346">[ thread ]</a> + <a href="subject.html#5346">[ subject ]</a> + <a href="author.html#5346">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit : +><i> 'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble: +</I>><i> > Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit : +</I>><i> >> Hi, +</I>><i> >> +</I>><i> >> As I upgrade my various machines (I only really have about 5, so not +</I>><i> >> that many) I'm running into a few packages that are missing (this is +</I>><i> >> inevitable). +</I>><i> >> +</I>><i> >> Nothing major just little things like trac and supybot etc. +</I>><i> >> +</I>><i> >> What is the best way to add these packages to the v1 tree? +</I>><i> >> +</I>><i> >> Using backports seems a little odd as this is "unsupported" and we don't +</I>><i> >> really want to encourage using it as a means to get the missing packages. +</I>><i> > +</I>><i> > If we do not want to have people use backports, we wouldn't have added +</I>><i> > it in the first place. +</I>><i> > +</I>><i> > I do think backport is perfectly suited for that. +</I>><i> +</I>><i> So the user that just wants to install supybot has to expose themselves +</I>><i> to the risk of updating to a backported version of gnome or KDE.... this +</I>><i> is hardly ideal. Especially for novice users. +</I> +One alternative would be to make sure that backports for version 1 are +fully supported and break nothing. + +><i> >> release is obviously frozen so no go there. +</I>><i> >> +</I>><i> >> The only real option is updates, but that should obviously have some QA +</I>><i> >> on it. +</I>><i> > +</I>><i> > Updates is not for new version of software, not for new softwares. And +</I>><i> > backporting something from cauldron is not a update. +</I>><i> +</I>><i> This seems like a strange statement as */updates on mdv was allowed to +</I>><i> have new packages in some cases (I've done it before, although I think +</I>><i> only for * == contrib), so I don't see why we have to restrict this +</I>><i> possibility in Mageia. +</I> +contrib/updates was basically not watched at all. People could send +anything without trouble, and there was no policy ( nor any enforcement +). That's not really the best example to use :) + + +><i> >> Perhaps we need to have some kind of exemption to get these missing +</I>><i> >> packages added? +</I>><i> >> +</I>><i> >> Does anyone have any opinions on this? +</I>><i> > +</I>><i> > Yes, I do. +</I>><i> > +</I>><i> > We have used backports in the past for that, and I see no reason to +</I>><i> > change that. +</I>><i> +</I>><i> This is fine in the regular course of distro evolution, but here we're +</I>><i> talking about users migrating from Mdv to Mga and finding "stale" Mdv +</I>><i> packages still installed on their system when they want (and we want to +</I>><i> provide) a Mageia version. This is very much a special case for this +</I>><i> transitional period but I feel it's an important one, particularly +</I>><i> *because* it's the first release. +</I> +All releases are equal. And we warned that we would not be able to do +everything, so of course, we will have problem with those that lived on +Mars under a rock, but I think that most people know that we couldn't +have all. + +><i> I think you're thinking in absolute terms rather than transitional +</I>><i> terms. In absolute terms I agree with you on principle, but I think we +</I>><i> need to deal with transitional issues gracefully and not treat them as +</I>><i> second class considerations. +</I> +It was not clear for me from your mail that this would be temporary. + +So I assume we can agree to enforce the "new packages go to backports +unless very specific and defined exceptions" policy for version 2 of the +release ? + +If this is temporary, it would be ok, provided we follows the usual +rules about handling updates. + +As we do not want to have untested rpms backported in */updates, this +mean that package must be checked by QA before ( and proper testing for +a new rpm is more that just checking it doesn't break ). + +So it should follow the proper policy ( once we agreed on that ). + +As discussed in the previous thread, that would for example mean that +the packager that submit the backport is not the one testing it and +giving the go, even if he can test before submitting to avoid wasting QA +time. + +Since we want to restrict to package that people have used and missed +for upgrade, I would also add that this part should be checked and +requires : +- a bug report saying "upgrade failed due to that" +- if we want to be inclusive, a forum post could do the trick ( provided +it is in english, or a bug referencing the forum ) +- package must be kept upgradable from mandriva 2010.1 +- ideally, the upgrade path should be tested, but I am pretty sure that +people will not :). + +Finally, I would also add that as soon a package is in updates or +release, the usual rules should apply ( ie, no more exception ). If I +push the package to */updates once getmail because it is missing, but +the next package do not go to */updates unless it fullfill the usual +rules. Any following backports goes to */backports. + +And, just to be clear, the policy only apply to version 1, for x86_64 +and i586. + +One question would be "what is a pacakge requires a complex backport", +for example, someone yesterday asked for darcs, that requires ghc, that +requires bootstrapping. + +Yes, no ? Why ? + +><i> > If the problem is that backports were too buggy in the past, then we +</I>><i> > should fix backports process, not bypassing them. +</I>><i> +</I>><i> I don't think this is particularly relevant. Backports are unsupported +</I>><i> generally. That's a given. +</I> +Before, it was Mandriva that said "we don't support backport", but we +can do thing differently. + +We do offer them, we spoke of the application made by Stormi to manage +backports request ( among others ), and it was asked to install it on +our servers. So to me, for something unsupported, it seems to be rather +well integrated. + +So the question is "what do people mean exactly when they say "backports +are unsupported" and what would it change when compared to updates, +which is supported by definition" ? + +Ie, I think we as a community support them to some extend, and so we +should explain what can people expect, and what they cannot. +And if possible, in a positive way ( as one issue we had with backport +was that people kept telling "do not use it", which is why people do not +use it ). + +Ie, I have a backport installed, would I receive new version, or not ? +I found a bug, can I fill it in bugs.mageia.org, or not ? +Etc, etc. + + +><i> If we encourage people to enable backports to +</I>><i> get missing packages (this is very distinct and separate from the +</I>><i> unsupported backports). +</I> +><i>From the user point of view, any package he doesn't have is a missing +</I>packages, be it due to upgrade from mandriva or because it was not +packaged when he needed :) + + +><i> > And if we start by pushing new version in update, people will soon +</I>><i> > wonder why the new version of X is in updates, while the new version of +</I>><i> > Y is not, just because we didn't have X in release and Y was there. +</I>><i> +</I>><i> I very much consider "nothing -> version X" quite different from +</I>><i> "version X -> version Y". I don't think it's a hard concept for anyone +</I>><i> to grasp. +</I> +We kept telling to people that we do not want to place new version in +update, and if we start to do the contrary, this is not really coherent. + +So while this can be justified, I think we should take in account +communication with users to clearly explain why we do, and why this is +temporary. + +I guess a blog post would do the trick, so would you be volunteer for +that if needed ? + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005332.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? +</A></li> + <LI>Next message: <A HREF="005364.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#5346">[ date ]</a> + <a href="thread.html#5346">[ thread ]</a> + <a href="subject.html#5346">[ subject ]</a> + <a href="author.html#5346">[ 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> |