[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian rolling: tentative summary



Josselin Mouette <josselin.mouette@ens-lyon.org> writes:

> Le lundi 02 mai 2011 à 19:31 +0200, Goswin von Brederlow a écrit : 
>> To those users that want newer software my next question would be "What
>> software?". My feeling there is that it is only some software, allways
>> the same software and used for the same use case: KDE / Gnome /
>> Multimedia stuff for the Desktop.
>> 
>> Looking at the other group, those that cherish the slow release cycles
>> and excelent stability and security support, shows a a large bias
>> towards servers that are either completly headless or where people don't
>> care about the latest sparkly desktop hype. They need to run and keep
>> running without having to upgrade them every 6 month.
>> 
>> If my impression is right then maybe there is something to say for
>> having a desktop and a server flavour like other distributions. It would
>> be wastefull to have a rolling release with all sources included if the
>> users only need a subset. The desktop users only want the new sparkly
>> KDE / Gnome / Multimedia stuff. They do not care about the latest
>> coreutils or latest postgresql.
>
> Iâ??ve seen such arguments to split the distribution between desktop and
> server components many times, but I still donâ??t buy them.
>
> First of all, the line is very hard to draw. The desktop requires server
> components (for example Apache binaries), and some daemons require
> desktop components (like Glib). Where do you put a GUI to configure
> iptables? or the necessary components to make remote desktops?

Which is why I don't want to completly split, as in not have the server
packages available in the desktop distribution. The way I imagine the
sparkly releases would contain a full package set or you would have

deb http://ftp.debian.org/debian stable main
deb http://ftp.debian.org/debian sparkly main

In both cases the "desktop distribution" would still have an apache and
postgresql and all that. Just not bleeding edge versions of those.

For the other way around, servers needing desktop components, the
components would still be there in the full release. The sparkly release
might have a newer version of libs but they must already be compatible
or have a new SONAME. So I would think there wouldn't be any (or at
least not many) problematic links between desktop and server parts.

> If you want to make a distinction between users, make it between those
> who want stable things maintained in the long term and those who want
> always the latest stuff. But there are desktop users in the former
> category and web applications developers in the latter.

So maybe throw away the lables like desktop and server and let the
sparkly release grow naturally. Lets start with an empty package set and
add packages that need a newer version. When there is a new KDE version
between stable releases then KDE can be added to sparkly. When there is
a new must have apache version then that can be added. There would have
to be some guidelines for when to add something and probably some nice
big flame wars. It would be something inbetween stable and volatile. But
I think with just a minimum of restrained on when to add a new version
the sparkly release would be a much smaller set of packages than a full
release and respectively less work to pull off.

MfG
        Goswin


Reply to: