(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
Attachment:
signature.asc
Description: PGP signature