(water under the bridge by now, but as I have written it
I suppose I can also sent my remarks for the archives/next time…)


Am Mon, Mar 17, 2025 at 11:57:56PM +0100, schrieb Hilmar Preuße:

another question for BD's. Due to a bug in ghostscript 10.04 it can't be
used on armel / armhf to build the asymptote package (version <= 10.03 & >= 10.05 are fine). How would you phrase that in the BD's:

Build-Depends: ghostscript
Build-Conflicts: ghostscript (= 10.04)

This is an exact match, so e.g. "10.04.0~dfsg-2+b1" doesn't match.
(Nor would my local rebuild/backport/whatever)

Build-Depends: ghostscript (<= 10.03) | ghostscript (>= 10.05)

Its probably preferable to go with ">= | <=" instead although the
difference is in practice very tiny: or-groups have a preference order,
so the most preferred option should come first.
Also, for some builds or-groups are stripped down to one aka the first
valid alternative mainly for reproducible reasons.

Note that most things starting with "10.03" are >> "10.03", so your
version restriction realistically limits to <= 10.02 upstream.
$ dpkg --compare-versions '10.03' '<<' '10.03.0'

Note also that e.g. "10.05.0~dfsg-1~" might be better for the >= version.
The trailing ~ allows for e.g. backports.


Debian has its own rules regarding version comparison and even if we
talk about it, the tools have no concept of "upstream version" so:
10.03-1 << 10.03.0~alpha1-1 << 10.03.0-1 << 10.03.0+really10.02-1

Other methods, I'm not aware of? Or should I simply rely on the fact that gs 10.04, will vanish from the archive sooner or later?

(The problem seems architecture-specific, so you could even add [arch])


This is mostly a personal choice entangled with the specifics.
In most cases I would say doing nothing is fine,
for the rest a lone >= is probably good enough.

Specifics that can influence that choice are e.g.:
Is it "just" failing to build or is a misbuilt produced
that destroys systems upon installation?
Is the build running for 7 days until it eventually fails?
Is the bad version likely to be encountered, was it e.g. released
with the last stable version or backports are being done?
Have derivatives picked it up for their releases?
Leaf package or e.g. involved in (cross-arch) bootstrap?
And most important: Did another maintainer/porter/… ask for it?


I know nothing about your package and next to nothing about gs,
but if I understand #1085120 correctly its an arch-specific
general problem in gs and as such I would suspect people having
bigger problems than your package not building and hence a
general hurry to upgrade (or someone who absolute can't upgrade
is inclined to backport patches at least).

So, I would do nothing as the real world impact might even turn
out to be negative (imagine the backported patches… now they also
need to patch your version restriction out).

At least for Debian there is no difference as your package will be built
in unstable and that is already >= 10.05 and I would assume it to migrate
to testing before anyone wonders if testing can build what it contains
(and for that question, having unsatisfiable dependencies or a FTBFS is
not really a meaningful difference as both is an RC-level failure).

Also a factor in your case: The choice at build time has no effect
on the binary dependencies of your package.


Note that depending on the answer to some of the questions, it
might even be a better idea to detect faulty versions upstream
and fail the build rather than going with Debian-specific deps.
(to end this mail with going full circle, see "other methods")


Best regards

David Kalnischkies

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmfaqm8ACgkQMRvlz3HQ eINLqg//RKNYaZ8Y9KbaMuxiRB/06RQltok+MjW0ybI+TGeM8m2MPg/d7xeGTqoA 2FjHuWUYEgBepgxKd94aPIqv8VNYmWeZE8rvBUKBZi9kPSLGb/SpBXeiCyBjI5l9 J9Pnha8HZkRBALTV8VUSkV5JETltdwDEpVSFicm98F5vmZ+LF5qHYj3hEdYBl+IN GTTegQlv3ydjBkH+XBWEIUOhox0IHT/wxYk52TfI5vUxMHwHrvF/k7BkuymGCQy+ dAgDrAJeCIDjdLpDLAw3Y6X+3ZYdTpGEar2J5eBK9P8rUxUR5mBkcqdebOOEZm/I Q+3T+UAKU/71R+TFj5/K204O0H3NBgoeioWf8mo/OdLGJvJ5DK3q1rMmUmEBYwwk 7Y6wCjGAEWVKw1TjuvUk2zbknjB2DaMjrVj76Qq7omSGJcYt/q6/l6IsKngxIDDg Cz9FnvsDTjOqxdvujrIsREy9QyAbsFtPtW9YRJ5IaxbzYWG3zWjScz6e2KCCVLPc 220za1Kax2nWvdQRFqrhvRGjcKAuIUZgqNmGWtmONdeQ9003eYCAIZbwEg12kx/C Q9rwCPodS5ULbqf0dnRbt+Ixa9S59ri73GR8YEM5sN46sjjdosDPG9Ja0c7dOmsr YV0S5itsk+duN9CAorefjljD8/CA10NTC+lEfH5HoKrDXEXWbaE=
=a+9l
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)