❦ 14 février 2018 21:11 +0200, Lars Wirzenius <l...@liw.fi> : >> > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8), >> > > > this will be true with X 1:1.6 as well. > ... >> That's exactly the point. You wanted X >= 1.8 and you get X 1.6. > > I don't think that's what you said, or at least it was hard for me to > understand it that way.
Totally possible. >> More concrete example (now a bit in the past). On Wheezy, you want to >> depend on a 1.8 JRE (you package independently). You put >> default-jre-headless (>= 1.8). Since you have forgotten about the epoch, >> this pulls Wheezy default-jre-headless (1:1.7-47+deb7u2). So you add the >> epoch to both your own package version default-jre-headless (1:1.8-1) >> and to the dependency. All good. You upgrade to Jessie and rebuild >> everything. Jessie comes with default-jre-headless (2:1.7-52) which >> shadows your default-jre-headless (1:1.8-1) package. > I think I now understand what you mean: you're actually worried not > that version numbers compare in illogical ways, but that people write > wrong versions in dependencies. In the example above, while in Wheezy, the dependency was perfectly correct. It became wrong because of the epoch bump (for no obvious reason). For software we distribute ourselves, this change can be caught at some point before the release (or by automation, like you suggest), but for people packaging stuff outside Debian, this can be far more painful. -- Don't stop with your first draft. - The Elements of Programming Style (Kernighan & Plauger)
Description: PGP signature