Re: blend-gen-control and UDD
Hi Ole,
On Thu, Mar 29, 2018 at 10:18:34AM +0200, Ole Streicher wrote:
> Hi (especcialy Andreas),
>
> I am going to implement UDD requests as an alternative to updating the
> blends dependencies from apt. Major driver is your interest in having
> architecture specific lists if required.
>
> However, I feel that this does not solve the problem, since it is a more
> general problem (or my understanding is just wrong): As far as I
> understand is that a task "foo" may have a dependency ("Recommends")
> "bar" that exists only on some architectures.
>
> Currently, blend-gen-control just looks in amd64. When the package
> exists there, it will be a "Recommends" in d/control:
>
> Package: blend-foo
> Architecture: all
> Recommends: bar
>
> When the package does not exist on amd64, it will go to "Suggests":
>
> Package: blend-foo
> Architecture: all
> Suggests: bar
>
> In case bar does not exist on f.e. amd64, you want instead to have
> something like
>
> Package: blend-foo
> Architecture: any
> Recommends: bar [!amd64]
> Suggests: bar [amd64]
>
> right? Note the "any" here -- "Architecture: all" package are not
> allowed to have architecture restrictions (Policy 7.1).
I think you rephrased the problem correctly.
> IMO this has some essential drawbacks: First, it will not work nicely
> when using multiple archs: Consider I have a package that I would like
> to "Recommend" but it exists only for 32 bit. Then, (assuming that one
> added i386 to the installed archs, and the MultiArch flags were properly
> set) it should pull the recommended package automatically from the other
> arch. In your approach however the foo is downgraded to Suggests and
> will not be installed by default. Old science software may have its
> difficulties with 64 bit; I have one of these packages in my longer-term
> queue.
I admit I have not thought about MultiArch before.
> Second, the Blends approach is isolated; in principle this should be
> applied to *every* package that Recommends a package possibly existing
> only on selected archs. For example, a Python package that Recommends:
> python3-pandas must in principle do the same (and therefore cannot be
> Architecture: all anymore). And the maintainer would need to keep an eye
> on this and update the Recommends any time the list of archs for these
> packages change. Sounds like really a lot unnecessary work. But is the
> consequence of interpreting the policy in your way.
>
> I interpret the phrase in Policy 2.2.1
>
> | In addition, the packages in main
> |
> | * must not require or recommend a package outside of main for
> | compilation or execution (thus, the package must not declare a
> | Pre-Depends, Depends, Recommends, Build-Depends, Build-Depends-Indep,
> | or Build-Depends-Arch relationship on a non-main package unless that
> | package is only listed as a non-default alternative for a package in
> | main),
>
> not being architecture specific: A Recommends: needs to be in main, but
> not necessarily on the same arch; thanks to MultiArch (whose approach
> specifically was that one can solve dependencies across architectures).
That interpretation makes sense to me.
> Using UDD however has the advantage to be closer to this (and solve the
> problem that a Recommends exists only of 32 bit). And it may be quicker
> than downloading the whole package list.
I also think: The UDD approach can at least solve the architecture
problem while fully ignoring MultiArch (which is strictly speaking
wrong). So we are in lots of practical cases doing way better than with
the amd64 based dependencies list. Considering that I fully agree that
the MultiArch problem is not Blend specific I tend to ignore this for
the moment until we have a general solution for this in Debian.
Thanks for bringing this up
Andreas.
--
http://fam-tille.de
Reply to: