ANN: Closing AC

[Aredridel]

On Sun, 2005-12-11 at 15:05 +0100, Jakub Bogusz wrote:
> On Sun, Dec 11, 2005 at 02:45:22PM +0100, Marcin Król wrote:
> > > It's ok as long, as we make ISO-s from time to time.
> > 
> > That is the part of "always in developement" idea.
> > 
> > > I can't see what's  
> > > bothering ppl bout dying ac and th. Windows 98 and 95 and ME died as well,  
> > > other distros also make new versions and move on forward.
> > 
> > For me personally if we will switch to "awlays in developement" distro 
> > it would be easier to:
> > 
> > 1) Maintain my machines, by simply doing poldek --upgrade-dist out of 
> > stable tree. Occasionally there will be need to do some manual upgrades 
> > like from postgres 8.0 to 8.1 which requires database dump/restore. Now 
> > lets assume that we will stay with current distro politics + we will 
> > release new version every year. So once a year I'll probably have to 
> > reinstall all the machines because version Z was released and X has 
> > reached an EOL.
> 
> But think about "big transitions", such as gcc - when most of
> C++/Fortran/Ada/GCJ-based Java stuff must be rebuilt. And many programs
> appear broken, so they wouldn't exist in distro even for few months.
> gcc 4.0 isn't so new now (about 8 months from 4.0.0 release has passed),
> but many programs still need fixes, sometimes non-trivial.

How possible are parallel installs? Could one not have both installed,
if packaged properly, and migrate as packages become fixed, eventually
having a system without GCC 3?

Perhaps it would be smart to define package sets:

AC + Gnome 2.12 + GCC 3
upgrade to AC + Gnome 2.14 + GCC 3 
install to AC + Gnome 2.14 + GCC 3 + GCC 4 
clean to AC + Gnome 2.14 + GCC 4

Each move like a mini distro upgrade, but without the long pain and
massive changes, each isolated into the package set. Like always in
development, but with tested groups of releases, not continuous updates.

Some continuous updates could happen within the framework, if each
module is a poldek repo with an updates repo attached, too.

Find sets of packages that mutually require upgrade -- like dist-upgrade
finds when installing -- and label them as distro "addons" (I don't like
the word) -- and you can upgrade entire subsets, without needing to
upgrade a whole distro.

Building this would require a few more tools, to check interdependencies
between repos. I don't think they would be hard to build. I think the
net win could be very big: stability, upgrade paths, rapid development,
short release cycle.

I have a friend who would like to not bother with many updates until a
new GNOME, then travel to where they have broadband and update. If he
could just enable a new repo and dist-upgrade, he'd be set very quickly.
Conceptually simple, manageable. For updates at home on dial-up
internet, he could just keep (security?)update repos for the groups of
packages enabled, and only do actual major updates when he has
broadband.

Aria