Updating software between releases - where backports/SRU isn't enough

Tim Hull thully at umich.edu
Sun Jul 29 01:59:28 UTC 2007


>
>
> For LTS releases I agree this is a problem.  I also think Ubuntu is
> addressing
> it in a sane way.  Most of the changes included in the upcoming 6.06.2 are
> related to supporting newer hardware.  My launchpad-foo isn't up to
> providing
> a link, but you can find a link of bugs that are targeted for 6.06.2.
>
> For non-LTS releases, I'm not convinced there's a sane way to approach
> this.
> I'd be curious if you have a specific proposal.
>

I'd say it is definitely an issue with both LTS and non-LTS releases -
though it is definitely much more of an issue with LTS releases (and Debian,
which has a release cycle approximately the same length as LTS).  I had a
couple ideas here with respect to both cases, though...


My idea would be to basically split the existing backports into two
categories:

1) An "Optional Updates" category, which contains supported release updates
that are not installed by default.  This would include high-demand userspace
application updates like Firefox 3.0 (if it came between releases).  It
would include some system-space updates, but only for bugfix purposes or
hardware support (a new kernel, for instance, or an Xorg video driver).  For
instance, issues such as my MacBook's lack of suspend would be resolved
here.

2) For all other backports, add an easy way to self-build packages from
source in addition to the existing unsupported backports section.  This
could be from the unstable release source, or from the proposed "Grumpy
Groundhog" section. Basically, one would add the appropriate source
repositories into Synaptic, and the latest binary and source releases would
be displayed with an option to "build from source" - which would fetch all
dependencies etc.  We could even add the option to set compiler flags for
advanced users (might get some Gentoo users to switch :)).  I do know apt
provides some of this infrastructure (apt-build etc), but it could be tested
and integrated.

I know this may be a completely unfeasible idea, but it is what I was
thinking of within the current release cycle.  IAJALU (I Am Just A Lowly
User), though...

Tim

P.S. Honestly, my preference would be for a slightly different release
cycle.  Each LTS release would be based off Debian stable (and would come
slightly after said Debian stable), and each succeeding release would be
based off the LTS with backported updates (i.e. we'd pull new versions of
Firefox, the kernel, etc in, but  we wouldn't update glibc just for the sake
of updating glibc.  Updates to be incorporated in the next release would be
backported on a rolling basis in the "Optional Updates" category.  This
would seem to result in more stable releases while making Ubuntu more
compatible with Debian. IANAUD, though...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20070728/28fecf71/attachment.html>


More information about the Ubuntu-devel-discuss mailing list