[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: chromium not in Squeeze: a bit of communication needed?



On Wed, 8 Sep 2010 12:57:28 -0400, Michael Gilbert wrote:
> On Wed, 8 Sep 2010 12:19:40 -0400, Joey Hess wrote:
> > Michael Gilbert wrote:
> > > A an option in the installer like volatile/security should address a
> > > lot of this concern.
> > 
> > Unless it installs the package from backports, the most the installer
> > can do is eliminate one or two of the three or four things users must
> > do to use it. All my comments about user discoverability/usability still
> > apply.
> 
> Here's what I think could be done:
> 
> 1.  Provide debian-backports-desktop which has a limited set of
> bleeding edge packages that desktop users want
> 2.  Make the priority of this release higher than that of stable, and
> have some high standards for the ftpmaster to control what gets in
> 3.  Provide debian-backports-server which is the current backports,
> just renamed, and operates the same way
> 4.  Provide an option in the installer called "I want bleeding edge
> desktop updates (provided via debian-backports-desktop)"
> 5.  Provide an option called "I want server backports (provided via
> debian-backports-server)"

This solution may be more complicated than necessary.  I just re-read
backports' documentation.  It looks like automatic updates are prevented
due to the use of the 'NotAutomatic' flag in the release file.  I'd be
interested in understanding the logic for that setting and debating
whether it could be disabled.

As for the need for pinning, that can be solved by judiciously choosing
package names.  The current instructions say to append '~bpo' to all
packages, which makes backport versions older than stable versions.  For
chromium and other fast-moving packages that should stay up to date, the
instructions could say to use '+bpo' which would make that a newer
version than stable.

Again, it should be up to the ftpmaster to review and OK (via request)
all '+bpo' uploads due to the risk of breakage on automatic updates.
Combine this solution with disabling 'NotAutomatic', and I think all of
the concerns are addressed.  Thoughts?

Best wishes,
Mike


Reply to: