A proposal for an always-releasable Debian

by cpeterso • 13 years ago

102 33 13 years ago

antihero4• 13 years ago

I dislike how "LAMP" is considered a first class citizen, still. Why is "LAMP" preferable to things like nginx, PostgreSQL, Python, Ruby, or other now extremely popular alternatives?

onli• 13 years ago

Those may be extremely popular alternatives. But they are alternatives to something, and that something is LAMP. LAMP is a standard one can count on being available on linux-distros, and it is a standard which makes it very easy to develop something for the internet on. As much as I like Ruby, I would not dare to assume that Apache+PHP alone isn't way more popular in terms of general use.

The one thing though that I count on getting replaced on that stack is MySQL, though the M might stay. If Debian hasn't done that already.

obviouslygreen• 13 years ago

But they are alternatives to something, and that something is LAMP.

This simply isn't true. Web development is done in many languages, and while the P in there stands for several of them, it's entirely inaccurate to suggest that any or all of them are somehow a default value deployment or development.

Web development deployment environments are not the sole purpose of Debian, and the purpose of non-'P' development languages is not to serve as potential but perpetually-sidelined alternatives to this arbitrary default.

petsos3• 13 years ago

Debian is a distribution for bureaucrats. For installations that are just being maintained. If you are anything close to hacker do yourself a favor and use something else.

mwcampbell2• 13 years ago

Hackers also appreciate having a stable, even conservative, foundation on which to build, especially when it's time to put a service in production, scale it to multiple servers, and keep up-to-date with security patches.

There is nothing to stop Debian users from using Rails, Django, Node.js, or any of the other alternatives to LAMP. SOme of them are even packaged in Debian.

StavrosK• 13 years ago

Edessa?

dangayle• 13 years ago

First thing I do whenever I install a fresh Debian copy is swap out stable for testing so I can get Python 2.7, then add the official repos for nginx.

laymil• 13 years ago

Now that Wheezy is Stable, you shouldn't have to do the first step.

grn2• 13 years ago

The Debian FAQ recommends using unstable because it can take some time for bug fixes to go into testing. I'm on stable right now but I'd been using unstable for about 6 months and it worked great.

zokier• 13 years ago

I must wonder why Debian needs to do 10 months of developing/bugfixing software in the first place. I mean most of the software is already supposedly "stable" releases from upstream, is it not? Maybe Debian should focus on working closer to upstream developers so that the software would be more directly usable out-of-the-box.

mike-cardwell• 13 years ago

Two headlines I've read in the last 24 hours:

  "International Space Station Goes Open Source, Dumps Windows XP for Debian"
  "Google's cloud dumps custom Linux, switches to Debian"

dbaupp• 13 years ago

But, for example, the interaction between the pieces of software, as well as, the Debian-maintained software might not be stable.

e12e3• 13 years ago

It's not so much the individual packages, it's the interaction between them, and dependencies. In this release, we got multiarch, which is quite an overhaul in how cross-compilation works (especially relevant for running 32-bit (often binary only, non-free) software under the amd64 architecture.

There are such issues as which version of libxml, libopenssl and even glibc certain packages work with (or especially, do not work with).

So, eg nginx upstream might test (mostly) against an upstream release of openssl and some libc, while the apache web server might be more conservative (this is a made up example, tomcat, especially legacy versions such as 6, might be a better example than apache httpd).

justincormack• 13 years ago

Multiarch took so long to ship that most of the proprietary binaries are now available in 64 bit. It is still marginally useful.

The testing issue is a big problem as up streams often have poor tests but that is an upstream issue really. Maybe the best solution is to provide CI frameworks for upstream to use that support current and future Debian versions easily (something like Travis but with more OS versions).

beatgammit• 13 years ago

) ftfy.

Even so, 10 months is a bit much. If the freeze were shorter, then Debian would have newer software. Fortunately, Debian releases are made roughly every 2 years, but even when Debian ships, it's already several months behind.

This isn't a problem for most servers, but it's a definite pain for developers like myself who use newer versions of software (extreme example, I use Arch) then try to backport to whatever's in the Debian repository. Sure, newer versions of software can be installed, but that kind of defeats the purpose of running Debian in the first place.

A shorter freeze means newer software in a release, which may reduce the need/temptation to use a package not in the stable repository, which is better for everyone.

vy8vWJlco• 13 years ago

In short form: I think the turn around time is increasing because Debian has to wait for conflicting interests to settle. Solution: stop waiting for everything including the kitchen sink, and only worry about including the highest-yield and most necessary software in "stable". Let the newest desktops, for example, stay in unstable and layer them on stable (Ubuntu could be a themed faster-moving layer that could use as much of the stable core as possible). With the decreased turnaround time for stable iterations (the Debian ecosystem's "core" platform), less stable layers (derived distributions) would actually become less of a burden to develop since they would have a base they can depend on - one that isn't too far away from bleeding edge, but still solid as a rock.

In long form: I think Debian should focus on getting the slowest-moving targets and major package-management design and minimally necessary policies well before, and above, faster-moving targets like UI and experimental features, etc... This means rethinking repos with an eye towards community division of labour along lines like turnover time (some tools simply haven't changed much in 20 years), popularity/necessity (kernel support, bootloaders, libraries), and bleeding-edge version expectations (desktop). In practice, Debian is pretty monolithic. People mostly install what's in their primary repo (the walled garden problem).

In practice, IMHO, this would mostly boil down to making it easier to pull in separate repositories under one install, layering them on those provided by stable and it's official installer, and other special-purpose repositories (for example, with an distro-specific virtual package to articulate the dependencies and make upgrades/downgrades/sidegrades clear and easy). I recognize a lot of motion in related areas (blends, debian live, stuff outlined in the article, etc - and a technically savy user can modify their sources), but I think that there is more than necessary being attempted under the name "Debian Stable" and this has been distracting from "stability" (and costing effectiveness). Specifically, the fastest-moving targets should not be considered part of Debian at all, IMHO, but separate distributions along lines that maximize stakeholder ownership and improve turnover time. It then becomes necessary to allow seamless distribution (repository) layering and interdependence (something the package manager can already do, but is difficult in practice for more than a few sources, even to experienced users). In essence, the package+repo system does not currently help much with forks and merges at that level - even though it is one of the most common problems in open software development. (Git has spoiled me.)

Ideally, IMHO, all Debian-based distributions should be installable from the same installer, even if they may want to provide their own (like Ubuntu), something that would be made possible because the packaging standards would have solidified to the point that other distro-builders (repo, and special-purpose package maintainers) can rely on them (my hope for "stable").

That said, I am just another "user" who prefers things not break over them looking brand new.

mwcampbell2• 13 years ago

The concept of reference installations reminds me of Ubuntu main versus universe, or the main RHEL repository versus Fedora's EPEL repo. Makes sense to me. Perhaps Debian should use separate repositories too, so the difference is highly visible when we browse packages.

e12e3• 13 years ago

Well, technically, there is already "contrib". I guess it is a little crazy to have as many packages in "main" as there is. Impressive, yes, but also a little crazy :-)

e12e3• 13 years ago

Now that backports is part of Debian, I think most of the issues with "out of date" packages are much less painful than they used to be. I suppose factoring main into "core" and "non-core", would make maintaining backports easier too - you could then test building a package against a smaller set of core packages and libs.

Packages needing newer versions of glibc, automake/autoconf, gcc/clang/ruby/python/perl etc are still tricky though.

grn2• 13 years ago

Currently contrib is used for packages that have compile-time or runtime dependencies on packages outside of the distribution (e.g. with dependencies in non-free).

popee• 13 years ago

Just two things.

Debian guys should really do something like OpenBSD package flavors. Sometimes you just don't need X,Y or Z support and it's pain to do this kind of stuff with Debian. I'm not sure if that is even possible in such rigid package managemenet system. Other thing would be to allow files/libs as dependencies. Those two things would give people more freedom and flexibility, but they are from start trying really hard to be anal with packages (even given the fact that .deb system is , at the same time, best and worst thing about Debian). So, guess, just forget about it.

A proposal for an always-releasable Debian

Related Stories