Re: Future releases of Debian
On Sun, Jul 20, 2003 at 06:09:31PM +0200, Christian Fasshauer wrote:
> Adrian Bunk wrote:
>
> >On Sat, Jul 19, 2003 at 08:49:29PM +0200, Christian Fasshauer wrote:
> >
> >
> >>...
> >>
> >
> >It's not technically impossible, although it's a non-trivial task if you
> >want to do it right.
> >
> Perhaps, it could be as far as possible automated. And the
> implementation effort shouldn't be to hard because the dependency and
> package stage check which decides to put a package from unstable to
> testing works very well and acts actually similar.
How exactly do you plan to automate e.g. the g++ 3.3 transition if you
backport KDE? Simply compiling these packages with g++ 2.95 without
changing the package names will make later upgrades to Debian 3.1
impossible.
IIRC the most popular KDE 3.1 backport tells you to remove your old KDE
packages before installing the new packages and an upgrade to Debian 3.1
will most likely work similar. This is OK for people who really want the
latest KDE, but it is clearly not acceptable for official Debian
backport packages.
Besides this, you still hit many of the open RC bugs in unstable.
Remember, an official backport would cover 11 architectures, so a
breakage on one of the architectures is a problem for you.
> >It would be some kind of official backports. In my
> >opinion, backports of more recent packages to an outdated Debian stable
> >are only a workaround, not a good solution.
> >
> For woody is there really not a chance, but after finishing sarge it
> could exist a level after testing which contains software, possible to
> be inserted into sarge. And this container is filled up the whole time
> and becomes emptied sometimes and this is the update. Even new packages
> could be introduced in that fashion.... However, each developer should
> try then to use dependencies that are as low as possible different (but
> working) from the current release. Or a second testing group needs to be
If you want the latest GNOME or KDE you need the latest versions of more
or less all packages in this area - that's nothing the package
maintainers are able to change.
> created which checks the lowest possible dependencies. The reducing
> product would have a quality between stable and testing.
Let's say you'd start this today for woody, the list below lists some
possible things to include:
- GNOME 2.2
- KDE 3.1
- support for kernel 2.6
- OpenOffice.org
- XFree86 4.3
This would be _much_ more than thousand packages altogether and the
binaries alone would fill approx. 3 CDs.
I don't think the effort to create a good backport of all these packages
is much lower than the effort to do a complete Debian 3.1 release.
> >The real solution is to get
> >a stable release of Debian at least once a year.
> >
> >
> I would be really thankful for that, but this could become a quite more
> difficulty task. I think, no Debian Developer wants to slow down the
> process of finishing a new Debian release and the amount of software
> grows up. Perhaps means more software more time for a result. ;-)
>...
My current impression is that independent of the number of pacakges
there is simply no visible plan when and how to do a freeze...
> christian
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: