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
