Prev: Building kernel image packages with make-kpkg, custom dependency
Next: schroot and automount
From: freeman on 15 Feb 2010 03:50
I installed apt-cacher because I wanted a way to reliably roll back one
version of a package in testing. This way, if a new version is buggy, the
way the recent xserver-xorg/mesa was for me, and I let it slip by
apt-listbugs, I may possibly choose the old version from apt-cacher rather
than nearly total my system messing with it, as I did.

It will be necessary for me to manually run the cleaning script on occasion
to avoid random deletion of old versions. For this reason I first chose
apt-proxy. It has a nice config allowing specification of an exact integer
for the number or version to retain for each release. Couldn't ask for more
than that.

However, I got python errors and the hour was late.

Has anyone else had success with such a plan?

Is pinning really necessary or can I get by with aptitude and my apt.conf
file:

APT::Default-Release "testing";

?

I did read the page on approx, pinning, repos and more by one of our prominent
list subscribers.

TIA!

--
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/20100215083210.GA11874(a)Europa.office
From: Rob Owens on 15 Feb 2010 10:20
On Mon, Feb 15, 2010 at 12:32:10AM -0800, freeman wrote:
> I installed apt-cacher because I wanted a way to reliably roll back one
> version of a package in testing. This way, if a new version is buggy, the
> way the recent xserver-xorg/mesa was for me, and I let it slip by
> apt-listbugs, I may possibly choose the old version from apt-cacher rather
> than nearly total my system messing with it, as I did.
>
I've used apt-cacher, and it worked well. However, I recommend
apt-cacher-ng (which I'm using now). I have Ubuntu and Debian machines
on my LAN, and apt-cacher did not keep the distros separate. There were
several cases where different packages from Ubuntu and Debian had the
same name and version number, and this caused problems with apt-cacher.
apt-cacher-ng solved this problem.

> It will be necessary for me to manually run the cleaning script on occasion
> to avoid random deletion of old versions. For this reason I first chose
> apt-proxy. It has a nice config allowing specification of an exact integer
> for the number or version to retain for each release. Couldn't ask for more
> than that.
>
> However, I got python errors and the hour was late.
>
> Has anyone else had success with such a plan?
>
> 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? If
not, then this shouldn't be necessary, but it won't hurt.

If you are running the testing distro, and all you want to do is control
the version of a specific package, then you can either pin it (apt
preferences file) or put it on hold (using aptitude).

-Rob


--
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/20100215151851.GA8138(a)aurora.owens.net
From: Freeman on 15 Feb 2010 13:30
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:

> >
> I've used apt-cacher, and it worked well. However, I recommend
> apt-cacher-ng (which I'm using now). I have Ubuntu and Debian machines
> on my LAN, and apt-cacher did not keep the distros separate. There were
> several cases where different packages from Ubuntu and Debian had the
> same name and version number, and this caused problems with apt-cacher.
> apt-cacher-ng solved this problem.
>

I looked at -ng. I don't run multiple distros but it is also supposed to be
light and resource friendly. It shouldn't be any trouble to install after
installing cacher.

> >
> > 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? If
> not, then this shouldn't be necessary, but it won't hurt.
>
> If you are running the testing distro, and all you want to do is control
> the version of a specific package, then you can either pin it (apt
> preferences file) or put it on hold (using aptitude).
>

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.

Seems the apt.conf file includes

priority 100
to the version that is already installed (if any).

priority 500
to the versions that are not installed and do not belong to the
target release.

priority 990
to the versions that are not installed and belong to the target
release.

Methinks a preferences file is required.

--
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/20100215182208.GA7203(a)Europa.office
From: Boyd Stephen Smith Jr. on 15 Feb 2010 14:00
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.

Keep in mind that stable/backports mixed with testing/unstable/experimental
isn't well-tested by the DDs. It should work, but if it breaks, upgrading
packages from stable/backports to unreleased versions might be the first step
in getting help, and doing that might be disruptive to your environment.

> 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.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss(a)iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
From: Freeman on 15 Feb 2010 14:40
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.
>
> Keep in mind that stable/backports mixed with testing/unstable/experimental
> isn't well-tested by the DDs. It should work, but if it breaks, upgrading
> packages from stable/backports to unreleased versions might be the first step
> in getting help, and doing that might be disruptive to your environment.
>
> > 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.

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

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.

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

--
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/20100215193019.GB7203(a)Europa.office
 |  Next  |  Last
Pages: 1 2
Prev: Building kernel image packages with make-kpkg, custom dependency
Next: schroot and automount