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@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.