PLD Linux and Obsoletes

[Patryk Zawadzki]

On 8/1/07, Jeff Johnson <n3npq at mac.com> wrote:

Oh, hi Jeff.

> On Aug 1, 2007, at 9:38 AM, Patryk Zawadzki wrote:
> > Smart treats all Obsoletes as final and in the above situation results
> > in cycling between foo and bar with each upgrade attempt. This is
> > certainly not the desired situation so I thought I'd ask here if there
> > were any plans to handle such situations (not very common in most
> > distros as they provide "the one and only app" for each task) by
> > ignoring Obsoletes that are matched by a virtual Provide (not matched
> > by a NameProvide).
> There's no simple solution within packaging for many reasons,
> not the least of which is whether Obsoletes: should be by RPMTAG_NAME
> or by RPMTAG_PROVIDENAME, and whether Obsoletes: should be
> persistent. Without clear answers to those questions, its impossible
> to design a packaging or depsolver solution.
>
> Meanwhile, the KISS principle says pin one of the two alternatives.
> smart almost certainly has that apt-like functionality.

Yes and I am willing to implement what I described above as a
downstream patch if anyone tells me where to do it in smart. Currently
smart is unusable for PLD.

> > Another issue I'm experiencing at the moment is that smart does not
> > handle "Requires: uname(release) >= 2.6.20" kind of system
> > dependencies introduced in recent releases of rpm. We also use those
> > and currently it's impossible to install such packages using smart.
> Doing
>      echo "uname(release) = 2.6.20" > /etc/rpm/sysinfo/Providename
> is one way to satisfy the dependency. Dunno what rpm is being used ...
>
> Upgrading rpm, or preparing packages that can be installed with
> functionality that is actually available on the client, is the better
> fix however.

[patrys at meaw SPECS]$ rpm -q rpm
rpm-4.4.9-4.i686

It's smart that complains about it (eg. when running "check"), not rpm.

I thought you'd guess that PLD follows you closely ;)

-- 
Patryk Zawadzki
Generated Content