Re: Non-normalised field Provides in UDD table
Hi Ole,
On Thu, Apr 12, 2018 at 12:02:38PM +0200, Ole Streicher wrote:
> Andreas Tille <andreas@an3as.eu> writes:
> > I mean we need different metapackages for say amd64, arm64, i386, etc.
> > I agree that this is no solution for MultiArch but from my point of
> > view that's rather a corner case. However, our metapackages are
> > currently simply broken for all architectures except amd64 and I'd
> > love to get this fixed in Buster.
> >
> > As I said blends-gsoc had some solution for this: [...]
> >
> > -Architecture: all
> > +Architecture: any
> > Recommends: abacas,
> > - abyss
> > + abyss [!s390 !hurd-i386 !kfreebsd-amd64 !powerpc !sparc !ia64 !kfreebsd-i386],
>
> That was what I meant: This problem is in no way specific for blends
> tasks, but is general for "Architecture: all" packages: You always may
> run into the problem that such a package has a recommendation (or even
> dependency) that is not fullfillable on one or the other architecture.
>
> Imagine f.e. when R would stop the support for 32-bit architectures.
> That would mean that all R packages (which are "Arch: all") cannot be
> installed on those architectures anymore, since the dependency cannot be
> resolved there. Would you then consider to rewrite all R packages to be
> "Arch: !i386 !powerpc ..."? And to maintain all of these dependencies in
> all R packages just to be in sync with the platforms supported by R? IMO
> that is out of question.
>
> What is the difference to a blends task med-bio with Arch: all and
> recommending a package that does not exist on s390x? What do we gain
> except getting MultiArch problems?
Hmmmm, I admit you have a point here. I've never seen it like this.
I need to sleep about this.
> > It has another really great feature. It has the following warning
> > output:
> >
> > WARNING:__main__:"filo" has been replaced with "bedtools"
>
> Where does it get this from? Is this issued when "filo" is a "Provides"?
Yes. The package filo is missing and bedtools provides it. That's a
hint to fix the tasks file to not mention packages that are replaced.
> > WARNING:__main__: **Missing package python3-bd2k has the following existing versions:
> > WARNING:__main__:python-bd2k
>
> Similarly here: in which cases you issue this?
I have not checked the code again (and lacking the time in the next
hours). But I once specified to the GSoC student that if the package
name has a version number and that package name is not found to replace
that number by '%' and seek for a match. Here you see the result. It
usually happens with library packages if the ABI version is appended to
the package name (even if tasks should not really specify library
packages but rather the lib*-dev package but as we have seen in the
libodil0-dev case sometimes these have versions as well). The
libodil0-dev package would have matched both tests (Provides and replace
version number by %).
Hope this clarifies things
Andreas.
--
http://fam-tille.de
Reply to: