Re: debian is too big
On Tue, Mar 09, 2004 at 01:11:32AM +0100, Philippe Strauss wrote:
> Dear Mr/Ms. Debian :)
Hey, we might have a knighted developer somewhere, and you don't want to
exclude them. <g>
> Like probably many other users, I'm facing a growing pain to stay
> on debian stable due to the fact that things like PHP and python
[...]
> Our job is to develop and we want to host what
> we build on debian, but debian stable is becoming less and less
> able to support what we build, we can't stay with PHP/Python dating
> from 2 years back.
Well, there is another possibility - you can manage a local archive of
package you are interested in, which tracks testing, doing the compatibility
testing each time you update your local package repository. That way, you
get some level of quality assurance, while still having a collection of
reasonably up to date software.
This only works, of course, if you've got a reasonably small set of
software, which is why it doesn't work so well for Debian. Since we're
trying to support so many different uses in a single software distribution,
there is a huge collection of software, with some impressive
interdependencies. Getting them all straightened out and working at the
same time is quite an effort.
And, of course, you can allow others access to your mini-collection, and
effectively become a distributor yourself. If it becomes popular, that
would be a possible impetus to get the support for creating mini-distros in
the main archive - the pool structure means that lots of versions of a
package can live side-by-side, for each mini distro. "Woody", "Sarge", and
so forth, would still exist as the "official" debian releases, but a lot of
users would go for the smaller collections, with their own release
schedules, names, and versioning, because they can get a "stable"
distribution more often.
> At the same time I'm wondering to the number of packages
> debian support.
> Someday I wake up and dreamed I was THE DEBIAN DICTATOR which
> bumped out 6000 packages at once. Just to keep a "core" debian
> of ~300 packages and some debian subproject around each big pieces
> like apache, php, python, xfree, non-web internet services etc..
It's a nice idea, but it doesn't work very well when there are lots of
subprojects that all have to be coordinated with each other.
For instance, if I want to have both the PHP and Python debian sub-projects
on the one box, but the two projects have dependencies on conflicting
packages, I'm screwed. As I add more subprojects onto the same box, the
problems get more difficult to keep in check.
The problem doesn't arise in your private repo, since you're tracking one
distribution of software, and just keeping a (presumably consistent)
snapshot of it for your own use. Backports and forward ports can and
probably will be a small part of it, but you're primarily just working from
the main distribution.
> More seriously, my point is:
> Is there any hope to one day, to adapt debian to the number of packages
> it bears and split release cycles between a core of 300-500 packages
> and having the rest of packages evolving at their own pace, following
> the core?
> syncing so much package around "release" schedule is becoming
> unrealistic. I'm waiting testing to become stable for so long.
I doubt it, because of the complicated dependency chains we end up with
because of the number of packages we try to support. About the best we'll
end up with is better support for debian-based mini-distros - these
"snapshots" taken from the main distro. But they will have one major
difference from the subproject concept - there'll be no guarantee that any
of the mini-distros will interoperate, so you'll need to pick a mini-distro
which suits your needs.
The added value that these derived distros will provide will be selection of
the most appropriate packages, and QA and integration testing as a
self-contained whole.
- Matt
Reply to: