On Thu, Sep 13, 2018 at 7:55 AM, Gerald Henriksen <ghenriks(a)gmail.com> wrote:
On Wed, 12 Sep 2018 09:44:21 -0400, you wrote:
>On Wed, Sep 12, 2018 at 9:34 AM Rex Dieter <rdieter(a)math.unl.edu> 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.
_______________________________________________
I believe you are correct.
If Krita-X needs at least Blah-3 and older version of Fedora are on
Blah-2, you can put the correct version of Blah in the module with
Krita.
Troy