Re: Apt for RPM question, blocking certain rpms

[Jeff Licquia <jeff@licquia.org>]

On Tue, 2003-10-07 at 15:24, mike808@users.sourceforge.net wrote:
> Steve wrote:
> > Assuming apt 0.5.x, put this in the RPM {} section in
> > /etc/apt/apt.conf:
> >     Hold { "^php$"; "^gd-devel$"; };
> > You get the idea...
> 
> No I don't. Would you mind putting this on the list of stuff to talk about
> either at a future meeting or here on the list?
> 
> I'm trying to get my head around this idea that the /etc/apt/preferences file
> and the /etc/apt/apt.conf file are actually two different ways to do some of the 
> same things, and mix this in with the fact that apt is really just a Perl script 
> or uses Perl somehow, since the documentation for apt.conf smells *a lot* like 
> Perl code with all of what looks like "packages/namespaces", anonymous hashes, 
> and regular expressions.

Here's a good way to remember it.

The apt.conf file is a way to configure general things about apt. 
Besides the RPM options, there are options regarding how things get
downloaded, how apt fixes hard dependency questions, debugging options,
and so on.

Pinning is entirely a package management thing, and it involves setting
preferences for where packages are supposed to come from.  It arose
largely as a reaction to Ximian Desktop; people would try XD on Debian,
not like it, and complain because it was nearly impossible to remove XD
and put regular Debian GNOME back on the system.  Basically, each
repository now can provide information about itself, and apt can do
queries on that information and prefer packages from certain
repositories based on those queries.

BTW, the apt.conf format is more inspired by the "new BIND" format (BIND
8 and later, as well as other ISC projects like dhcpd) than it is by
Perl.  Apt is most definitely not "just a Perl script". :-)

> Is one preferable to the other (pinning packages and versions in apt.conf vs
> preferences)?

Pinning is more complicated, and no one has come up with a good easy UI
for it.  (Though I have some ideas.)  OTOH, you can do things with pins
you can't do with holds.

For example, Erich could keep his custom RPMs in a local apt repository,
and maintain his boxes with a single pin:

Package: *
Pin: release o=Museum
Pin-Priority: 1001

With that preferences file, apt would actually even downgrade installed
packages newer than those in the Museum repository.  That way, he
wouldn't be forced to manually install updates to his custom RPMs, yet
he could also "apt-get dist-upgrade" without fear.

> If they're both equivalent, which, IYHO, is headed for "deprecated" status?
> Or is it an issue of dealing with repositories or not?

I imagine RPM::Hold was put there by someone who wanted to duplicate the
functionality of the "hold" status in Debian.  That status is a dpkg,
not an apt, setting, but apt respects it.

On Debian, dpkg holds are nice and quick compared to setting up pins,
but if a good UI were ever written for pinning, that would probably be
the best place to set these things.
-- 
Jeff Licquia <jeff@licquia.org>

-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.