Re: implementing an official Debian backport framework for the current stable release
Peter Samuelson wrote: [Mark Farnell] To address this problem, I am thinking about a possible framework for official debian backport to the current stable release: - to create a backport repository of the most recent packages on testing that have significant improvements / addition of important http://backports.org/ Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
implementing an official Debian backport framework for the current stable release
Hi! I have been using Debian for 2 years and I am currently using the Sarge, which is the current stable release because it is well tested, stable and doees not change the packages and dependencies every day. However this also deprive me from accessing the updated software (e.g. wine, firefox 1.5 (expected to be released in late Nov) and openoffice 2.0) without having to update to testing/unstable, which would be a very large download. This failure of getting stability, convenience as well as access to updated software at thte same time is one of the main factor putting people off Debian. To address this problem, I am thinking about a possible framework for official debian backport to the current stable release: - to create a backport repository of the most recent packages on testing that have significant improvements / addition of important functions to the public (e.g. openoffice 2.0, wine 0.9, firefox 1.5 (when it is officially released), PHP 5 etc.) - packages of the basic environment such as gcc, glibc, X, GNOME and KDE are EXCLUDED fro the backport repository to avoid massive downloads/upgrades - These packages must be build under the standard current stable build environment and their dependencies must be fully satisfied by the repository current stable release (i.e. the environment including the gcc, glibc, X, GNOME and KDE are strictified to the parameters of the stable release) - the backport repository are available for i386, IA64, amd64 and ppc architectures only to limit maintenance workload - the backport repository are available on SEPARATE CD set and independent from the parent set. - backport repository CD sets are to be released in 4-6 month intervals (releases are registered as point releases) until the release of rc3 of the testing distribution - the most current point release of the backport repository is to be supported by a security team (official or unofficial) - backport repository for each architecture should not exceed 2GB to avoid overload of server space and resource of security team What do you think about the feasibility of such a backport framework and its effectiveness in making a good compromise between stability, usability and access to the most updated software/function?
Re: implementing an official Debian backport framework for the current stable release
[Mark Farnell] To address this problem, I am thinking about a possible framework for official debian backport to the current stable release: - to create a backport repository of the most recent packages on testing that have significant improvements / addition of important functions to the public (e.g. openoffice 2.0, wine 0.9, firefox 1.5 (when it is officially released), PHP 5 etc.) The nature of Debian's archives and tools (apt, in particular) makes it very easy to do this sort of thing without being especially affiliated with the Project at all. If you feel the need to compete with backports.org, dotdeb.org, apt-get.org and other such sites, there is no need to arrange to use the official mirror network. You can even release CD images if you wish, along with normal package updates and security updates. Also, the update candidates are, of course, inherently subjective. Some people will care much more about, for example, Linux 2.6.14 or subversion 1.3.0 (not yet released) than they ever will about PHP 5. Last time someone tried to do an official backport release like what you're describing, it was known as slink-and-a-half, and apparently never was actually blessed by the Project. (My memory fails me concerning the details, and I'm too lazy to look them up, but if you are interested in this field, I'm sure slink-and-a-half is quite googlable.) What do you think about the feasibility of such a backport framework I think people in Debian-land use the word framework far too often. But that's neither here nor there. I also think competing with backports.org et al is something you should do outside the Project, until you've demonstrated advantages over these other repositories. Alternatively, you could work *with* them. signature.asc Description: Digital signature
