> > Hardy, but Hardy also provides libfoo2. The source package may not > > care (it requires either libfoo1 | libfoo2). But the Gutsy .deb cannot > > depend on libfoo2 (only libfoo1 is available on Gutsy), while the > > Hardy .deb can. So two .deb's would be very beneficial. > > "Build-depends: libfoo1-dev | libfoo2-dev" would work just fine and > libfoo2 should be a shared-lib and replace libfoo1 automatically in > hardy. I can't clearly see the benefit of having bin-NMUs, specially > compared with all the confusion it might cause. That's exactly what I'm doing in the source package: "Build-depends: libfoo1-dev | libfoo2-dev". But Build-Depends alternatives in the source package DO NOT translate into Depends: alternatives in the binary package. Correct? For examples, if the package that Build-Depend's on "libfoo1 | libfoo2" is only built on Gutsy, the resulting .deb will depend on libfoo1 (not on libfoo1 | libfoo2). When installing such a .deb on Hardy, it will not be able to take advantage libfoo2's existence. This was the whole point and the main reason I want different .deb's -- maybe I should have explained in more detail from the beginning. -- Dan
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)