[systemd-devel] Mkosi and downstream release cycles and their support

[Jóhann B. Guðmundsson]

Greetings


Not sure if this is the right place for mkosi and casync discussions 
probably better create seperated mailing list for both of these 
components ( lates issue against mkosi seems to be a user problem not a 
bug ).

Anyway we have had two bugs reported against mkosi today one of which is 
requesting a new release of mkosi so the Arch community can update and 
create images with the latest Fedora releases and another one that an 
Ubuntu user is trying to create image of an older Ubuntu release which 
does not seem to have properly supported systemd ( which arguably simply 
is unsupported but then there needs to be an error msg to the user )

The Arch related bug/request indicates that the release cycle of mkosi 
needs to be tied to the release cycle of atleast every major 
distribution ( Arch,Fedora,Debian,OpenSuse ) however this will not 
scale, let alone when *every* distribution that ships systemd/mkosi will 
ask to be included, the code most certainly will become un-maintainable 
and quite ugly, quite fast.

The latter requires some kind of policy regarding obsolete of 
distribution ( noticed that few EOL fedora releases seem to be supported 
in the code ) which arguably should never be handled upstream let alone 
hard coded ( arguably upstream should just support latest stable + next 
release )

Cant these whole which distro is supported and on which release be put 
in a file to be read by mkosi,then that file can be update/maintained by 
downstream without having to wait for a new release of mkosi ( and 
downstream can decide that for themselves and deal with those support 
questions and matter ).

Another architectual thing ( and this might be an oversight on my part 
but ) how does mkosi.extra,mkosi.postinst scale along with corresponding 
mkosi.$distribution file?

Does one have to create mkosi.$distribution, mkosi.extra.$distribution 
directory, mkosi.postinst.$distribution for upstreams to deal with 
fragmented distribution mess downstream ( /etc/sysconfig/ red hat ism, 
different package names,  cert location, the all needless deviation that 
resides downstream )

How has this been thought through ( seperate directory's, git repo for 
each distro or what? )

JBG