diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 | 
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 | 
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2012-June/016330.html | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip  | |
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016330.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016330.html | 172 | 
1 files changed, 172 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016330.html b/zarb-ml/mageia-dev/2012-June/016330.html new file mode 100644 index 000000000..919615f60 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016330.html @@ -0,0 +1,172 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> +   <TITLE> [Mageia-dev] Proposed Feature:Backports_update_applet +   </TITLE> +   <LINK REL="Index" HREF="index.html" > +   <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposed%20Feature%3ABackports_update_applet&In-Reply-To=%3C4FD3B7D3.7040609%40laposte.net%3E"> +   <META NAME="robots" CONTENT="index,nofollow"> +   <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> +   <LINK REL="Previous"  HREF="016309.html"> +   <LINK REL="Next"  HREF="016331.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> +   <H1>[Mageia-dev] Proposed Feature:Backports_update_applet</H1> +    <B>andre999</B>  +    <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposed%20Feature%3ABackports_update_applet&In-Reply-To=%3C4FD3B7D3.7040609%40laposte.net%3E" +       TITLE="[Mageia-dev] Proposed Feature:Backports_update_applet">andre999mga at laposte.net +       </A><BR> +    <I>Sat Jun  9 22:53:39 CEST 2012</I> +    <P><UL> +        <LI>Previous message: <A HREF="016309.html">[Mageia-dev] Proposed Feature:Backports_update_applet +</A></li> +        <LI>Next message: <A HREF="016331.html">[Mageia-dev] Proposed Feature:Backports_update_applet +</A></li> +         <LI> <B>Messages sorted by:</B>  +              <a href="date.html#16330">[ date ]</a> +              <a href="thread.html#16330">[ thread ]</a> +              <a href="subject.html#16330">[ subject ]</a> +              <a href="author.html#16330">[ author ]</a> +         </LI> +       </UL> +    <HR>   +<!--beginarticle--> +<PRE>blind Pete a écrit : +><i> Samuel Verschelde wrote: +</I>><i> +</I>><i>     +</I>>><i> Following Backports opening due soon, and since our policy is that +</I>>><i> backports are supported (security, bugfix), we need a way to push backport +</I>>><i> updates for users who installed backports. Otherwise, we can't really say +</I>>><i> that we're providing security updates to our backports. +</I>>><i> +</I>>><i> My feature proposal is to implement something similar to what mgaonline + +</I>>><i> MageiaUpdate does for updates, but for backports, with some changes due to +</I>>><i> the fact that users will rarely want that "all" packages on the system be +</I>>><i> updated from backports when the backports media are activated. +</I>>><i> +</I>>><i> <A HREF="https://wiki.mageia.org/en/Feature:Backports_update_applet">https://wiki.mageia.org/en/Feature:Backports_update_applet</A> +</I>>><i> +</I>>><i> I don't think I can do the dev myself. I can work on more detailed +</I>>><i> specifications with a developer though. +</I>>><i> +</I>>><i> Samuel +</I>>><i>       +</I>><i> There are a multiple ways that this problem could be handled. +</I>><i> Yours is one. +</I>><i> +</I>><i> Samuel's way: +</I>><i> +</I>><i> Need "something" to know that a backport package +</I>><i> has been installed, to remember that fact, and to do an extra +</I>><i> backport update search when looking for updates. +</I>><i> +</I>><i> It would need to keep working if the user changed desktop +</I>><i> environments, or even stopped used a desktop and just used +</I>><i> the command line.  Does mgaonline do this?  There could be +</I>><i> room to improve that. +</I>><i> +</I>><i> If it can be detected that a backport package has been installed +</I>><i> (or less efficiently, detect that a backports repository +</I>><i> has been activated) set up a cron job (or reconfigure mgaonline) +</I>><i> and leave it like that for the life of the installation. +</I>><i> +</I>><i> Geeks way: +</I>><i> +</I>><i> Only use urpmi as a command line tool and edit urpmi.cfg with vi. +</I>><i> +</I>><i> When activating a backports repository mark it as an update +</I>><i> repository.  Then update with "urpmi --excludemedia [backport media, ...]" +</I>><i> accepting all suggestions, followed by "urpmi --auto-select" +</I>><i> and look at what is offered before accepting. +</I>><i> +</I>><i> My suggestion: +</I>><i> +</I>><i> Add "bp" to the package name and have separate backports update +</I>><i> repositories. +</I>><i> +</I>><i> Users would then be able to cherry pick from backports and +</I>><i> updates should _just work_ without extra intervention. +</I>><i> +</I>><i> The only difficulty that I can think of is, when a backport +</I>><i> (or backport update) package is pushed to updates.  It would +</I>><i> not be necessary to do a real update but the rpm database +</I>><i> should be updated such that version N-bp supersedes version N. +</I>><i> (And the N-bp packages should be removed from the repositories.) +</I>><i> +</I>><i> Can anyone see any holes in the logic? +</I>><i> +</I>><i> What would be easiest to implement? +</I>><i> +</I>><i>     +</I>You got me thinking :) +- Just marking all backport repos as update repos is almost enough to  +solve the problem, in terms of the tools installing the backports.   +Great idea ! +We just have to tweak the tools so that a backport is only installed as  +an update of a backport. + +- Note that we should allow a non-backport to replace a backport, as  +will likely be encountered in a release update.  If the versioning is  +properly done (according to established packaging policy), a  +non-backport in a newer release will have a higher version number, thus  +replacing the backport. + +- Functioning as an update, it would only replace already installed  +backports, once the tools are appropriately adjusted. + +- As with any update repo, one could always explicitly install a  +backport which is not already installed.  No special treatment is  +required for this. + +- using "bp" in the file name is nice and short, and definitively marks  +it as a backport for the tools, and for the user once installed.  (I  +would put it in the revision field.) +I like this approach, as it doesn't matter from where the package is  +installed; it will always be recognized as a backport. + +So I'm suggesting a variation of the last 2 solutions. +I think that this would be relatively easy to implement. +The trick is to find the right place in the code for the tweaks. +(tv could probably do it really fast.) + +--  +André + +</PRE> + + + + + + + + + + + + + + + + +<!--endarticle--> +    <HR> +    <P><UL> +        <!--threads--> +	<LI>Previous message: <A HREF="016309.html">[Mageia-dev] Proposed Feature:Backports_update_applet +</A></li> +	<LI>Next message: <A HREF="016331.html">[Mageia-dev] Proposed Feature:Backports_update_applet +</A></li> +         <LI> <B>Messages sorted by:</B>  +              <a href="date.html#16330">[ date ]</a> +              <a href="thread.html#16330">[ thread ]</a> +              <a href="subject.html#16330">[ subject ]</a> +              <a href="author.html#16330">[ 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>  | 
