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

Re: Why back-porting patches to stable instead of releasing a new package.



On Wed, Jul 23, 2003 at 07:09:01AM -0500, Luca - De Whiskey's - De Vitis wrote:
> On Wed, Jul 23, 2003 at 01:19:25PM +0200, Sander Smeenk wrote:
> > The same happened with one of my packages: snort. There was a /really/
> > old release in stable, because new uploads didn't make it in time. There
> > were a couple of reasons why it would be good to have a new upstream
> > version of the snort package installed in stable. But the Debian Policy
> > forbids it.
> 
> This is another example, that i like: who would ever use an old IDS?

After reading "Future releases of Debian" and all other ideas
(backporting etc.), another idea: Why not break up the one
monolithic[1] Debian into parts? We could begin with separating it
into "base" and "not base" where base corresponds more or less with
the base system and not base corresponds with all other things (apps).

As base is quite small, it could be released more frequently. The not
base part could evolve independent from the base part.

The not base part could be split further into parts. These parts could
be things related to mailservers, things related to webservers,
database servers, IDS, end-user workstations, ... Because each of
these not base parts are smaller, they too can be released more
frequently. 

In fact, this comes down to creating several Debian subprojects[2]:
one for the base part (kernel, common infrastructure, ...) and several
others for the not base parts.

This would also mean that each of these subprojects can use a certain
released version of the base part as basis i.e. some subprojects could
evolve faster than others e.g. "Debian-workstation" could be based on
Debian-base version 1 while "Debian-mailserver" could be based on
Debian-base version 2. Ideally, it could also mean that several
subprojects could be combined (e.g. when they depend on the same base)
in one installation.

This would certainly mean lots of work, especially regarding handling
bugs, upgrades, security fixes, ... (as each of the subprojects would
have their own responsibility), but, complexity can only be resolved
by other complexity.

[1] Debian's pro's are also becoming contra's: one single source for
all packages combined into one well tested whole is good, but not that
flexible, who's using all these packages on one single machine?, ...

[2] I don't know if they should be subprojects or what is sometimes
called "distro's based on the Debian meta-distro".


There are probably lots of comments on this, but I just wanted to get
this out of my head.

cu,

-- 
lenaerts.frank@pandora.be

gpg fingerprint: A41E A399 5160 BAB9 AEF1  58F2 B92A F4AB 9FFB 3707
gpg key id: 9FFB3707

Those who do not understand Unix are condemned to reinvent it, poorly."
-- Henry Spencer

Attachment: pgpCw9o6Ob1uy.pgp
Description: PGP signature


Reply to: