diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016427.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016427.html | 211 |
1 files changed, 211 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016427.html b/zarb-ml/mageia-dev/2012-June/016427.html new file mode 100644 index 000000000..d511068c2 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016427.html @@ -0,0 +1,211 @@ +<!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=%3C4FD71A69.1070204%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016412.html"> + <LINK REL="Next" HREF="016439.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=%3C4FD71A69.1070204%40laposte.net%3E" + TITLE="[Mageia-dev] Proposed Feature:Backports_update_applet">andre999mga at laposte.net + </A><BR> + <I>Tue Jun 12 12:31:05 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016412.html">[Mageia-dev] Proposed Feature:Backports_update_applet +</A></li> + <LI>Next message: <A HREF="016439.html">[Mageia-dev] Proposed Feature:Backports_update_applet +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16427">[ date ]</a> + <a href="thread.html#16427">[ thread ]</a> + <a href="subject.html#16427">[ subject ]</a> + <a href="author.html#16427">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>blind Pete a écrit : +><i> andre999 wrote: +</I>><i> +</I>><i> +</I>>><i> blind Pete a écrit : +</I>>><i> +</I>>>><i> Samuel Verschelde wrote: +</I>>>><i> +</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 +</I>>>>><i> backport updates for users who installed backports. Otherwise, we can't +</I>>>>><i> really say 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 +</I>>>>><i> due to the fact that users will rarely want that "all" packages on the +</I>>>>><i> system be 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> +</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>>>><i> +</I>>><i> You got me thinking :) +</I>>><i> +</I>><i> Thinking is always dangerous. ;-) +</I> +I guess I like living dangerously :) + +>><i> - Just marking all backport repos as update repos is almost enough to +</I>>><i> solve the problem, in terms of the tools installing the backports. +</I>>><i> Great idea ! +</I>>><i> We just have to tweak the tools so that a backport is only installed as +</I>>><i> an update of a backport. +</I>>><i> +</I>><i> Because the contents of the backport repositories changes during +</I>><i> the life of an installation it is desirable to... well... um... +</I>><i> "update" the database about that. +</I>><i> +</I>><i> +</I>>><i> - Note that we should allow a non-backport to replace a backport, as +</I>>><i> will likely be encountered in a release update. If the versioning is +</I>>><i> properly done (according to established packaging policy), a +</I>>><i> non-backport in a newer release will have a higher version number, thus +</I>>><i> replacing the backport. +</I>>><i> +</I>><i> If they had the same version number you would not want to do a +</I>><i> real update, but you might want to adjust the database. I have +</I>><i> no idea if that would be more trouble than it is worth. +</I> +Presently on a release update, all packages are replaced (if they exist +in the release), even if they are updates identical to the package in +the release being installed. This is (at least in part) because we +ensure that the update has a version number (counting the revision) less +than that of the release. +It shouldn't be different for backports. + +>><i> - Functioning as an update, it would only replace already installed +</I>>><i> backports, once the tools are appropriately adjusted. +</I>>><i> +</I>><i> There are a couple of ways to do that. The simplest that I can think +</I>><i> of is to split "backports" into "backports" and "backports update". +</I>><i> Allow cherry picking from "backports" and apply "backports update" +</I>><i> automatically. +</I>><i> +</I> +I was thinking of cases where the user chooses to "update" their +system. New versions of backports already installed would be presented +as updates, along with those from the update repos. +Just as we don't have any update-update repos, it wouldn't make sense to +have backport-update repos either. +Not every user would choose to install every proposed update from the +update repo. +In such cases, the update is proposed the next time the user asks for +updates. +Similarly, available backport updates won't necessarily be installed the +first time, but should be proposed the next time the user asks for updates. + +I would favour these backport updates being offered even if the backport +repos are not active. +However to see all backports, in normal install situations, it makes +sense to require that the backport repos be active. +When the backport repos are active, during updates we could even show +backports as updates to non-backport packages, but I'm not sure that I +would favour that. I would prefer the installation of a backport to be +more of an exceptional case. My impression is that most users tend to +install all updates presented, without necessarily thinking of the +consequences. + +-- +André + +</PRE> + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016412.html">[Mageia-dev] Proposed Feature:Backports_update_applet +</A></li> + <LI>Next message: <A HREF="016439.html">[Mageia-dev] Proposed Feature:Backports_update_applet +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16427">[ date ]</a> + <a href="thread.html#16427">[ thread ]</a> + <a href="subject.html#16427">[ subject ]</a> + <a href="author.html#16427">[ 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> |