blend-gen-control and UDD
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).
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.
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).
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.
Best regards
Ole
Reply to: