> Launchpad checks if the binary version is 'publishable' anything else > can't be accurately checked, unfortunately. > Note that 'installable' and 'fully-functional' are also different concepts. I meant "will be able to satisfy binary dependencies and install cleanly". I'm not sure if that would be "publishable" or "installable". > It's not only about the archive topology, but mainly for packaging consistency. > If foo-bin works fine for gutsy and hardy why would you have to > rebuild it and in case it doesn't work as expected in a later series > the issue should be fixed and documented as a new version of the It would be useful to have a different binary for Hardy (even when the Gutsy binary works) in the cases when Hardy provides updated libraries that the package uses. Say libfoo1 is available both in Gutsy and 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. > package. So the evolution goes on, step by step. How would this work? Would I need to maintain three separate source packages (one for Debian unstable, one for Hardy and one for Gutsy)? Even though the exact same source package would build fine on all distros and create different .deb's with different functionality (see point above)? -- Dan
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)