[Mageia-dev] E17 packaging

Thu Oct 27 17:21:32 CEST 2011

Am 27.10.2011 17:10, schrieb Michael Scherer:
+> Le mercredi 26 octobre 2011 à 23:12 +0200, Florian Hubold a écrit :
+>> Am 26.10.2011 22:06, schrieb Michael Scherer:
+>>> Le mercredi 26 octobre 2011 à 18:58 +0200, Florian Hubold a écrit :
+>>>
+>>>> If keeping old releases unchanged from distro to distro version is
+>>>> your vision of improving quality and more satisfying for our end-users,
+>>>> that's not my vision, sorry.
+>>> Then we should simply remove e17 altogether. Because, by choice of the
+>>> developpers, it is not stable enough to be packaged.
+>>>
+>> Yes, altogether that would be a logical conclusion, sadly but true.
+>> Seems some maintainers can actually be worse than infamous 'nobody'.
+>>
+>> How to deal with that on the upgrade to mga2 in packaging terms,
+>> display a message to E17 users to the extent of:
+>>
+>>      "... e17 has been removed to improve on mageia overall quality,
+>>      please use another window manager / desktop environment ... "
+>>
+>>
+>> And please: this is meant as a serious question following the
+>> above conclusion ...
+> That's a good question but in fact, the situation is not really new.
+> That's already something we should do for any software dropped.
+>
+> Either we drop because something do not work anymore ( for example,
+> something unmaintained upstream, not rebuildable and no one able to fix
+> ), or we drop because we replace.
+>
+> Replacing is seamless and we do it quite often, dropping is not.
+>
+> I would propose that we add a conflict on mageia-release, and make a
+> note in release notes. So on upgrade, package is removed, and people
+> have documentation.
+OK, sounds reasonable.
+>
+> Now, for the other problem of providing e17 without bypassing all our
+> update procedure, there is several possible solutions :
+>
+> 1) We could move that to another repository, outside of Mageia, with
+> different rules until that's sutable to be integrated properly. 3rd
+> parties repos are bad IMHO, but if people do not want to follow the
+> policy for whatever reasons, that's unavoidable.
+>
+> 2) We could find a way to not place some packages to stable release.
+> That would be quite complex, but doable. This way, people could use e17,
+> but only if they run cauldron. Thus, we are free of any
+> support/stability requirement.
+>
+> 3) We could ship the stable part ( ie, those with a tarball like eina,
+> etc ) and provide a script to compile/install the missing part from
+> svn, since this would also free use from support/stability requirement,
+> and as a bonus, let anybody keep the newest version ( because again, I
+> doubt that e17 developpers are interested into getting old bug reports,
+> given past and current interactions ). Of course, we should warn people
+> upon installation that they are on their own, that their e17 will be
+> updated often ( for the same reason about developpers )
+> . And of course, this assume that no updated tarball are needed for the
+> stable part.
+FWIW, not all of the tarballs are releases, there are also development snapshots.
+
+So basically we have the choice of stable, but incomplete and outdated E17,
+E17 only for cauldron users with added complexity for the distro, and no E17 at 
+all?
+> There is several way, and that's just the ones I can think in 5 minutes.
+>
+> But e17 is a package that we always drop sooner or later, and once in a
+> while, discovered again, and then dropped again.
+Nice to hear (after it was imported).
+