On Mon, May 26, 2008 at 11:35 PM, Dan <danmbox@xxxxxxxxx> wrote: >> > 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? yes, 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. No, unless libfoo2 replaces libfoo1 in hardy. > 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. I suspect it can be better discussed with MOTU guys and using a hands-on approach ;) It's certainly not an isolated problem of your package. [] -- Celso Providelo <celso.providelo@xxxxxxxxxxxxx> IRC: cprov, Jabber: cprov@xxxxxxxxxx, Skype: cprovidelo 1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)