Calling for a new openSUSE development model

Posted Jun 17, 2012 14:47 UTC (Sun) by joib (subscriber, #8541)
Parent article: Calling for a new openSUSE development model

Some thoughts about the Linux distro model:

http://liw.fi/rethinking-distro-dev/

https://plus.google.com/u/0/109922199462633401279/posts/H...

https://plus.google.com/u/0/109922199462633401279/posts/V...

The model of "freeze the world, release at once" just doesn't scale. I think Ingo Molnar is right on the mark - there needs to be a minimal "core OS" distro, and the release cycles of the rest should not be tied to the release cycle of the "core OS". (The "core OS" release cycle should probably follow the Linux kernel, to bring new drivers to users ASAP.)

In order to solve the "foo" depends on "libbar" issue, where libbar is not part of the core OS, packages could either include whatever libraries they need (beyond those provided by the core OS), with e.g. some fs-level deduplication mechanism as suggested by Ingo M. Alternatively, one could provide separate libbar packages, provided that the system would be designed to support parallel installation of multiple package versions - for shared libraries maybe some RPATH type mechanism similar to OSX frameworks could work.

to post comments

Calling for a new openSUSE development model

Posted Jun 17, 2012 20:11 UTC (Sun) by drag (guest, #31333) [Link] (11 responses)

It's just a blatently wrong approach to try to package all the software in existence for a general purpose operating system with each operating system release.

This is were it is fundamentally broken and is a terrible idea.

A operating system exists for the sole purpose of making applications easier to write and easier to use. It is quite possible to simply eliminate the OS completely and just run each application you want on bare hardware, but nobody wants to do that because it would require a stupidly large amount of work on behalf of the application designer and is not user friendly.

[quote]The model of "freeze the world, release at once" just doesn't scale. I think Ingo Molnar is right on the mark - there needs to be a minimal "core OS" distro, and the release cycles of the rest should not be tied to the release cycle of the "core OS". (The "core OS" release cycle should probably follow the Linux kernel, to bring new drivers to users ASAP.)
[/quote]

This is what is required.

You have a _minimal_ number of layers. Each layer is to it's job and changes within the layer have to minimally impact the layers above it and below it.

something like this from low to high:

* Hardware

* Kernel layer

* Minimal OS layer. The 'Unix layer'. Low level system utilities, daemons, and libraries specifically used to manage hardware, start up system, notify user space about changes to the environment, and system-specific administrative interfaces. Probably low-level graphical stuff too.

* Application environment layer. Or the application stack layer. For desktops this would be the 'Desktop Environment' of choice. For servers it could be 'LAMP', 'Java Tomcat', 'Oracle Database', 'C development', 'Android' or whatever.

* Applications installed by users/administrators or written by users for specific things they want to accomplish. Games, applications, server-side scripting for web apps, etc.

The first two layers form the 'Core OS'. Above that you start to branch out into multiple choices.

So irregardless of what 'core os' is users can go out and simply install 'KDE desktop environment' from KDE. Get Gnome from Gnome project. If distributions want to maintain repositories of software they don't build the packages themselves if possible and instead fetch them from the upstream projects.

Then you let each desktop environment layer producer fend for itself. Let them figure out how they are going to bundle libraries and handle versioning and all that. Application developers and users will then be free to choose whatever works best for them.

Calling for a new openSUSE development model

Posted Jun 18, 2012 14:24 UTC (Mon) by nix (subscriber, #2304) [Link] (9 responses)

Then you let each desktop environment layer producer fend for itself.

That works great until you realise that a good few things the GNOME guys regard as quintessentially GNOME (e.g. glib) are used not only by other desktop environments (both KDE and xfce use glib) but even by what could be considered core system components if they can be considered anything (e.g. both syslog-ng and systemd use glib). Indeed syslog-ng migrated *from* its own object model *to* glib -- asking it to migrate back so that a core system component does not depend on a piece of a desktop environment is unlikely to be received well.

Calling for a new openSUSE development model

Posted Jun 18, 2012 18:09 UTC (Mon) by joib (subscriber, #8541) [Link]

Well, then the "core OS" can include glib; I don't think it's worth getting too worked up by some idea that glib belongs "higher" up in the stack. If it's needed by some "core" component, then so be it. If GNOME, KDE, or some other (set of) packages requires a different version of glib, they can use a separate version (say, a different so version number or by using RPATH).

I suppose, in general one could (and should?) argue which packages/libraries should or should not belong to the core. But I don't think arriving at some consensus on this matter is the biggest hurdle for this approach, but rather getting buy-in for the general idea.

Calling for a new openSUSE development model

Posted Jun 18, 2012 19:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

glib by now should be considered a 'core' package. Besides, glib developers are very careful with backwards compatibility. So there's no reason to leave it out of the "core" profile.

IMO, all core libraries should be designed to be backwards compatible _forever_, just like libc or kernel ABI. That should be the main criterion for their inclusion.

Calling for a new openSUSE development model

Posted Jun 18, 2012 23:01 UTC (Mon) by nix (subscriber, #2304) [Link] (6 responses)

IMO, all core libraries should be designed to be backwards compatible _forever_, just like libc or kernel ABI. That should be the main criterion for their inclusion.

Agreed... but that rules out glib, glib 3 is not ABI nor API compatible with glib 2, and that was quite recent.

Calling for a new openSUSE development model

Posted Jun 18, 2012 23:05 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, it's OK in itself if glib-2 is going to be supported for the foreseeable future. Besides, right now it's a good time to make one clean break and design something that can endure and THEN standardize on it.

Calling for a new openSUSE development model

Posted Jun 19, 2012 1:49 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

I don't think it rules out Glib. Glib along with a significant amount of the GNOME platform(not things like GNOME Shell) including but not limited to GTK and Gstreamer maintain ABI compatibility for a long time. So does Qt et all.

When they do break it, they announce it widely and make both versions parallel installable which is really the best way to handle it unless you want to never ever break ABI compatibility which I think is a unreasonable expectation for anything higher up than say glibc.

Calling for a new openSUSE development model

Posted Jun 19, 2012 14:22 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

unless you want to never ever break ABI compatibility which I think is a unreasonable expectation for anything higher up than say glibc.

Why not? X11 did it. Furthermore, with symbol versions it's not even hard to do.

Calling for a new openSUSE development model

Posted Jun 19, 2012 21:33 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

Because higher up layers make mistakes which they dont want to be struck with forever. If it was trivial, everyone would be doing it already.

Calling for a new openSUSE development model

Posted Jun 20, 2012 16:12 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (1 responses)

I wouldn't ask them to be stuck with their mistakes forever, as long as they honour the proper sequencing of "create new; deprecate old; discard old". Some projects tend towards conflating "create new" and "discard old" into a single step. This is an understandable temptation, but one that should, as a general rule, be resisted by anyone working on a project that has (and wants to keep) actual users outside the project.

Calling for a new openSUSE development model

Posted Jun 20, 2012 17:44 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

This is how popular libraries like glib do development. I was just noting that the "discard old" step is a ABI break.

Calling for a new openSUSE development model

Posted Jul 5, 2012 10:13 UTC (Thu) by philomath (guest, #84172) [Link]

You are (more or less) describing Arch Linux.
And that's (part of) why I use it.