On Mon, May 26, 2008 at 9:43 PM, Dan <email@example.com> wrote:
>> 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
Checking if binary dependencies can be satisfied in the archive domain
(PRIMARY + PPA), can be tricky. I'm not sure we want to go down in
this track full of race-conditions. We don't even do such checks for
>> 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.
"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.
>> 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)?
The rule is actually can be as simple as: When you have to change
either packaging data or the upstream source itself to make it work in
a specific series, you need to create, upload and build another source
version. The opposite is not always true, when the binary from a
previous series installs fine in all other newer series you don't need
to rebuild the source, copying source & binaries will be okay, unless
there is a problem somewhere else, like pathological ABI changes that
are either well known and documented or went in unnoticed
I'm sure MOTU guys will be happy to help you with specific issues
about your packages, to minimize the number of packages while keeping
them consistent across multiple ubuntu series.
Celso Providelo <firstname.lastname@example.org>
IRC: cprov, Jabber: email@example.com, Skype: cprovidelo
1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469
launchpad-users mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users