Prev: Building kernel image packages with make-kpkg, custom dependency
Next: schroot and automount
From: Boyd Stephen Smith Jr. on 15 Feb 2010 15:40
On Monday 15 February 2010 13:30:19 Freeman wrote:
> On Mon, Feb 15, 2010 at 12:59:33PM -0600, Boyd Stephen Smith Jr. wrote:
> > On Monday 15 February 2010 12:22:08 Freeman wrote:
> > > On Mon, Feb 15, 2010 at 10:18:51AM -0500, Rob Owens wrote:
> > > > On Mon, Feb 15, 2010 at 12:32:10AM -0800, freeman wrote:
> > > > > Is pinning really necessary or can I get by with aptitude and my
> > > > > apt.conf file:
> > > > >
> > > > > APT::Default-Release "testing";
> > > >
> > > > This effectively pins all not-installed packages from testing at 990
> > > > (according to man apt_preferences). Are you running a mixed system?
> > >
> > > Yeah, testing with an unstable here and there. I've never noticed a
> > > downgrade to unstable or experimental resulting from default priorities
> > > or apt.conf priorities.
> > >
> > > But that won't help with rollbacks or a favorite lenny/backport.
> > >
> > > Looked at the debian wiki, man apt_preferences and Boyd's preferences
> > > file, which seems a well worked out example.
> >
> > > Methinks a preferences file is required.
> >
> > Mixed systems that are supported with no configuration change:
> > stable/backports
> > unstable/experimental
> >
> > Mixed systems that need Default-Release set properly:
> > stable/testing
> > testing/unstable
> > testing/unstable/experimental
> >
> > Any other mixing will need a preferences file.
>
> Thanks Boyd. That is an interesting implementation chart.

It's a side-effect of the priorities that are applied before you touch your
/etc/apt/preferences file. Default-Release pins something to 990. Backports
and experimental are tagged specially in either their Release or Packages file
so they are pinned to priority 1.

Technically, stable/testing/experimental, stable/unstable,
stable/unstable/experimental, and stable/experimental could also be run with
just Default-Release set and testing/experimental can be run with no
configuration. I don't recommend any of these for any reason -- there would
be too many dependency issues.

> My system = Section 2, Item 3, if I stay away from stable/backports.
>
> Except for package rollbacks! Could a rollback to a version no longer
> included in any release represent a deviation from

First, package downgrades aren't supported. Just a warning in general. The
old package can't be modified to "understand" any of the changes to your
system that the new package made.

IME, this hasn't been a problem. Still, a purge/reinstall cycle is usually
safer than a downgrade, but even that may not work with every package. (In
particular, I don't believe DMBSes in Debian remove the data files when
purged.)

> testing/unstable/experimental ?

Yes. If you file a bug that "touches" one of the package versions no longer
in any Release file, it is very likely the first thing you'll be asked to do
is upgrade to the current testing/unstable/experimental.

> Also, just thought of the presence of a few proprietary debs and debs I've
> built. They existing ones haven't effected anything to date.

That won't be a problem if their package name doesn't match one in the
repositories listed in /etc/apt/sources.list{,.d}.

> However, could a rollback represent an incursion on the priority system?

With testing/unstable/experimental, you'll have your Default-Release set to
testing so that package versions in testing get priority 990, package versions
in unstable get priority 500, and package versions in experimental get
priority 1.

0. If there is a versioned dependency apt-get / aptitude will satisfy it; it
will not take into consideration versions that do not satisfy the dependency.

1. If the version you have installed is less than the version in testing apt-
get / aptitude will want to upgrade it to the testing version.

2. If the version you have installed is greater than the version in testing,
but less than the version in unstable, apt-get / aptitude will want to upgrade
it to the unstable version.

3. If the version you have installed is greater than the version in unstable,
apt-get / aptitude will not want to upgrade it.

You can use individual package pins to alter this. Pinning your currently
installed version to (501-)990 would prevent 2 above, but not 1. Pinning your
currently installed version to 991(-999) would prevent both 1 and 2 above.
Pinning your currently installed version to 1 would cause 3 above to upgrade
your package to experimental instead.

IANADD. TINASOODP.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss(a)iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
From: Freeman on 15 Feb 2010 20:20
On Mon, Feb 15, 2010 at 02:33:05PM -0600, Boyd Stephen Smith Jr. wrote:
> On Monday 15 February 2010 13:30:19 Freeman wrote:
> > On Mon, Feb 15, 2010 at 12:59:33PM -0600, Boyd Stephen Smith Jr. wrote:
> > >
> > > Mixed systems that are supported with no configuration change:
> > > stable/backports
> > > unstable/experimental
> > >
> > > Mixed systems that need Default-Release set properly:
> > > stable/testing
> > > testing/unstable
> > > testing/unstable/experimental
> > >
> > > Any other mixing will need a preferences file.
> >
> > Thanks Boyd. That is an interesting implementation chart.
>
> It's a side-effect of the priorities that are applied before you touch your
> /etc/apt/preferences file. Default-Release pins something to 990. Backports
> and experimental are tagged specially in either their Release or Packages file
> so they are pinned to priority 1.
>
> Technically, stable/testing/experimental, stable/unstable,
> stable/unstable/experimental, and stable/experimental could also be run with
> just Default-Release set and testing/experimental can be run with no
> configuration. I don't recommend any of these for any reason -- there would
> be too many dependency issues.
>
> > My system = Section 2, Item 3, if I stay away from stable/backports.
> >
> > Except for package rollbacks! Could a rollback to a version no longer
> > included in any release represent a deviation from
>
> First, package downgrades aren't supported. Just a warning in general. The
> old package can't be modified to "understand" any of the changes to your
> system that the new package made.
>
> IME, this hasn't been a problem. Still, a purge/reinstall cycle is usually
> safer than a downgrade, but even that may not work with every package. (In
> particular, I don't believe DMBSes in Debian remove the data files when
> purged.)
>

Right. This would be an immediate rollback to the next-most recent archived
version of the apt-cacher proxy in the case that I allow an intolerably
buggy package. Some packages could fail to downgrade. Backups will be
available.

> > testing/unstable/experimental ?
>
> Yes. If you file a bug that "touches" one of the package versions no longer
> in any Release file, it is very likely the first thing you'll be asked to do
> is upgrade to the current testing/unstable/experimental.
>

.. . .

>
> > However, could a rollback represent an incursion on the priority system?
>
> With testing/unstable/experimental, you'll have your Default-Release set to
> testing so that package versions in testing get priority 990, package versions
> in unstable get priority 500, and package versions in experimental get
> priority 1.
>
> 0. If there is a versioned dependency apt-get / aptitude will satisfy it; it
> will not take into consideration versions that do not satisfy the dependency.
>
> 1. If the version you have installed is less than the version in testing apt-
> get / aptitude will want to upgrade it to the testing version.
>
> 2. If the version you have installed is greater than the version in testing,
> but less than the version in unstable, apt-get / aptitude will want to upgrade
> it to the unstable version.
>
> 3. If the version you have installed is greater than the version in unstable,
> apt-get / aptitude will not want to upgrade it.
>
> You can use individual package pins to alter this. Pinning your currently
> installed version to (501-)990 would prevent 2 above, but not 1. Pinning your
> currently installed version to 991(-999) would prevent both 1 and 2 above.
> Pinning your currently installed version to 1 would cause 3 above to upgrade
> your package to experimental instead.
>

I decided on a preferences file for caution and for future developments. Thus far:

|Package: *
|Pin: release a=testing
|Pin-Priority: 990

|Package: *
|Pin: release a=unstable
|Pin-Priority: 700

|Package: *
|Pin: release a=experimental
|Pin-Priority: 500

|Package: *
|Pin: release a=lenny/volatile
|Pin-Priority: 300

|Package: *
|Pin: release a=stable
|Pin-Priority: 100


To rollback a package to a previous version existing only in my apt-cacher
archive:

|Package: < package_name >
|Pin: version < nnn* >
|Pin-Priority: 1001

(Interesting that preferences is too finicky of a file to include that as
comments.)

lenny/volatile is for freshclam.

A standard update with aptitude before and after didn't show any changes.

It would be interesting to see how aptitude's resolution suggestions are
affected.

--
Kind Regards,
Freeman


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100216011026.GA4420(a)Europa.office
First  |  Prev  | 
Pages: 1 2
Prev: Building kernel image packages with make-kpkg, custom dependency
Next: schroot and automount