Re: Why back-porting patches to stable instead of releasing a new package.
On Wed, Jul 23, 2003 at 04:17:57PM +0200, Frank Lenaerts wrote:
>...
> > > 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.
> > >...
> >
> > This will result in a complete chaos.
>
> Why exactly? Just like we have had different versions of libc, gcc,
> ... in Debian (as a whole), we will have different versions of them in
> "Debian-base" upon which the rest is built. What you mean with "chaos"
> here, is what I mean with "other complexity" below.
libc5 is a leftover from a _big_ transition, it's not used by anything
inside Debian.
There's only one version of gcc used to build the packages, e.g. two
versions of the same library with the same so-name but compiled with
g++ 2.95 and g++ 3.3, respectively, must conflict with each other. If
one pacakge depends on the g++ 2.95 version and another one on the
g++ 3.3 version you can't install both pacakges at the same time.
> > E.g. how do you plan to ensure smooth upgrades from any combination of
> > parts to any other combination of parts?
>
> Upgrades would only be possible in:
>
> (1) base itself (of course)
> (2) a subproject i.e. you cannot upgrade a "workstation" to a
> "mailserver" branch (this would be a migration instead of an upgrade)
What do you install in your scenario on a mailserver that is also used
as a workstation?
> > > 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.
> > >...
> >
> > Nonsense.
> >
> > If it's too complex, it's time to rethink and restructure the thing to
> > make it simple enough.
>
> That's what I mean. Try to remove complexity by restructuring
> it. However, by restructuring things, you will also introduce other
> complexities (i.e. most people feel it as complexity because it is
> different/new).
Your scenario is complex and creates complex problems.
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: