[Mageia-dev] Proposal: Updating released versions (long post)

Sat Oct 9 15:46:08 CEST 2010

Luca Berra a écrit :
+>
+> On Sat, Oct 09, 2010 at 11:10:36AM +0200, Renaud MICHEL wrote:
+>> On samedi 09 octobre 2010 at 05:45, andré wrote :
+>>> Note that configuration files that have been changed from the 
+>>> installation default are often already saved.  (Generally ".old" is 
+>>> appended to the configuration file name, sometimes ".new" to the new 
+>>> configuration file.)
+>>
+>> But here you are only talking about system-wide configuration files, 
+>> which are known of rpm as they are part of the package and marked as 
+>> config files.
+>> But what about user specific configuration files?
+>> For the easy kind, where a program will have a single configuration 
+>> file (or dedicated directory), a pre-inst script could find it in the 
+>> home of each users and backup them. But you have cases of programs 
+>> which have configuration scattered in multiple shared directories 
+>> (like KDE), or even non-deterministic configuration files and it can 
+>> become very tricky to find all the files to backup.
+>> And you have the really hard kind, where the same configuration file 
+>> may be shared by different packages. For example, plasma applet 
+>> configurations are stored in a few ~/.kde4/share/config/plasma* files.
+Good point.  So user-specific configuration files would have to be taken 
+into account.
+BTW, there is a similar complication for some Gnome packages.
+So it would take a lot more time and effort to accommodate such rollbacks.
+However most packages would be much simpler to reliably roll back.
+So it seems useful that packages be marked as suitable for rollback (or 
+not).
+> +1
+> this is the very problem why i believe rollbacks are not that easy
+>
+Because the rollback will be automatic and must be very reliable, it is 
+not something to be taken lightly.  A malfunctioning rollback would be 
+considerably worse than the current manual rollback process.
+
+Note that insisting that all backports depend on the same versions of 
+required packages as the distro release for which the backport is made 
+will considerably reduce one potential source of problems.  As well, if 
+a new version of a particular application has important format changes, 
+perhaps there should be a policy of not making backports for it.
+So candidates for rollbacks would be mostly restricted to applications 
+developped and tested for the current release of the distro.
+Thus the utility of automated rollbacks would be considerably reduced.
+
+Another 2 cents :)
+
+- André (andre999)
+