Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


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

"Smart" package manager troubles



I'm using the Smart package manager with SUSE 10.2.  Smart seems to be
positioned as the Grand Unified Package Manager, although quite
honestly it's not clear to me what it offers that apt doesn't, and apt
is certainly more mature.

I'm using quite a few repositories beyond the base ones.  Sometimes
multiple repositories contain different versions of the same packages,
and due to the way different packagers compile things at different
times, sometimes a newer version of one package matches up with an
older version of another.  The problem here is that whenever that
happens "smart upgrade" wants to upgrade one of the packages and
downgrade the other.  If I actually do that, then the next time I run
"smart upgrade" it wants to reverse this action, apparently ad
infinitum.  If a package has to be removed to allow another package to
upgrade, then obviously it won't be automatically reinstated when I
next run smart upgrade.  As a result, to avoid blowing away a lot of
packages I have to do all upgrades manually (usually through the GUI,
unless we're only talking about a few packages).  Currently, I get
something like this:

# smart upgrade
Loading cache...
Updating cache...               ######################################## [100%]

Computing transaction...

Upgrading packages (5):
  kipi-plugins-0.1.3-100.pm.2 at i586
  knoda-0.8.2-24 at i586
  mozilla-xulrunner181-1.8.1.2-15.1 at i586
  openh323-1.19.0.1-40.pm.4 at i586
  pwlib-1.10.7-0.pm.0 at i586

Downgrading packages (8):
  digikam-0.9.1-0.pm.1 at i586              libexiv2-devel-0.12-101.pm.1 at i586
  gwenview-1.4.0-29.1 at i586               libkexiv2-0.1.1-0.pm.0 at i586
  hk_classes-0.8.2-23 at i586               pwlib-1.10.7-0.pm.0 at i586
  libexiv2-0.12-101.pm.1 at i586            pwlib-devel-1.10.7-0.pm.0 at i586

Removing packages (2):
  epiphany-2.16.3-38.4 at i586              kphotoalbum-20070423-1 at i386

37.7MB of package files are needed. 5.4MB will be freed.

Confirm changes? (Y/n): n

What appears to be going on here, for example, is that it wants to
upgrade kipi-plugins to the latest Packman-built version, but that
requires an older version of libkexiv, so it downgrades that, and
since the version of kphotoalbum I'm using was compiled against the
newer version, it apparently wants to remove it.  Or so it appears.

Of course, when I was using apt (with SUSE 10.0), this would happen
also, but "apt upgrade" refuses to downrev or remove packages; it
simply holds these packages back and they have to be installed
manually, with "apt install".

Smart provides ways to lock packages, but this means that they won't
be automatically upgraded either.  It also provides a way to assign
different priorities to different channels (aka repositories), but
that's simply a bigger hammer: it always gives the packages from a
higher priority channel priority over packages from a lower priority
channel, when all I want to do is to not downgrade packages.  Is there
something I'm missing somewhere that will actually do the right thing
here?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org