On Thu, Sep 13, 2018 at 10:55 AM Gerald Henriksen <ghenriks@xxxxxxxxx> wrote: > > On Wed, 12 Sep 2018 09:44:21 -0400, you wrote: > > >On Wed, Sep 12, 2018 at 9:34 AM Rex Dieter <rdieter@xxxxxxxxxxxx> wrote: > >> > >> Matthew Miller wrote: > >> > >> > On Wed, Sep 12, 2018 at 12:27:03AM +0200, Luigi Toscano wrote: > >> >> It does not make sense to do it for Frameworks (which is always keeping > >> >> the API), nor for the bundle known as KDE Applications (where you want > >> >> the last version), nor for the applications which independent release > >> >> schedule (Krita, Krusader, Tellico, etc; same as KDE Applications). > >> > > >> > One thing that you could do, if you want, is only maintain a single branch > >> > and spec file for each of these which would build across all current > >> > supported releases... > >> > >> Now that part does sound appealing, is essentially what we do for plasma > >> releases already by hand. > >> > > > >We could technically do this now simply by ignoring the other branches > >and just tell fedpkg to kick off builds against the master branch all > >the time. Modules do not solve this specific problem. Allowing us to > >use fedpkg to push to multiple releases simultaneously without work > >would help more. > > My (possibly incorrect) understanding is the modules, being a form of > container like Docker, would allow you to include say a library > version different than provided by the underlying Fedora installation. > So it would make it possible to say ship the latest Krita on all > versions of Fedora even if a library it requires version X of is at > X-1 on the previous Fedora release(s). > > While this isn't so much an issue for any KDE sig maintained libraries > it could be an issue for other libraries. Modules do not imply any form of containerization. In fact, modules primarily just output RPMs that install just like anything else. They just have built-in generated conflicts and such across other "module packages" of its kind and non-module variants. These could be used as an input for making containers, though. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@xxxxxxxxxxxxxxxxxxxxxxx
