FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Launchpad User

 
 
LinkBack Thread Tools
 
Old 05-26-2008, 07:43 PM
Dan
 
Default Copy packages to same PPA, different distro

> 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

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-26-2008, 07:59 PM
Pau Garcia i Quiles
 
Default Copy packages to same PPA, different distro

Quoting Christian Robottom Reis <kiko@canonical.com>:

> On Mon, May 26, 2008 at 09:09:19PM +0200, Pau Garcia i Quiles wrote:
>> I know but I'm not sure copying a binary between different
>> distributions (for instance, Gutsy and Hardy) makes sense, as the
>> binary would probably not work due to linkage issues.
>
> Copying forwards should be okay. Copying backwards will usually not work
> (unless the libraries really didn't break binary compat).

Not necessarily. If I build for Gutsy but the library breaks ABI
compatibility in Hardy, the Gutsy binary won't work in Hardy (and of
course the Hardy binary won't work on Gutsy, either).


--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-26-2008, 08:11 PM
Pau Garcia i Quiles
 
Default Copy packages to same PPA, different distro

Quoting Celso Providelo <celso.providelo@gmail.com>:

[...]
>> - Automatically copying packages between two PPAs. For instance, for
>> Zumastor we have two PPAs, zumastor-team and zumastor-releases. Everytime a
>> svn commit is done to the Zumastor repository, a package is built and
>> published to the zumastor-team PPA. On the other hand, only the stable
>> releases are published to the zumastor-releases PPA (ATM, manually copied
>> from zumastor-team). Automating this would make life easier.
>
> Interesting setup, it seems to be the adopted pattern for all
> Product-related PPAs, development & release.
>
> Are you imagining something kind of programmatic way to trigger the
> copies once you are happy with QA ? a API ?

I've forward this e-mail to Will Nowak, who is in charge of the script
which automates package building of Zumastor. He knows better than me.
One thing he'd surely like to have is an RSS feed of the packages a
PPA publishes (currently for Zumastor we are scraping).

>> - Automatically building a package for more than one release (in the same
>> PPA or in a different one). For instance, I may want to build my package for
>> Gutsy, Hardy and Intrepid. ATM, either I manually copy the package (which
>> does not work) or I upload the source three times (which is a PITA)
>
> Right, propagating source & binaries once they are built ...
>
> That's indeed a good idea. Can you file a bug about it, please ?

I've filed bug #235064. This could be as easy as supporting the Debian
Policy as stated in
http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
(it says you can specify several distro releases in the
debian/changelog file)



--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-26-2008, 08:21 PM
"Celso Providelo"
 
Default Copy packages to same PPA, different distro

On Mon, May 26, 2008 at 9:43 PM, Dan <danmbox@gmail.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
> "installable".

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
ubuntu packages.

>> 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 <celso.providelo@canonical.com>
IRC: cprov, Jabber: cprov@jabber.org, Skype: cprovidelo
1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-26-2008, 08:24 PM
"Celso Providelo"
 
Default Copy packages to same PPA, different distro

On Mon, May 26, 2008 at 9:59 PM, Pau Garcia i Quiles
<pgquiles@elpauer.org> wrote:
> Quoting Christian Robottom Reis <kiko@canonical.com>:
>
>> On Mon, May 26, 2008 at 09:09:19PM +0200, Pau Garcia i Quiles wrote:
>>>
>>> I know but I'm not sure copying a binary between different
>>> distributions (for instance, Gutsy and Hardy) makes sense, as the
>>> binary would probably not work due to linkage issues.
>>
>> Copying forwards should be okay. Copying backwards will usually not work
>> (unless the libraries really didn't break binary compat).
>
> Not necessarily. If I build for Gutsy but the library breaks ABI
> compatibility in Hardy, the Gutsy binary won't work in Hardy (and of course
> the Hardy binary won't work on Gutsy, either).

That's a 'pathological' case and should be documented as such. It
certainly will affect more than PPA copies.

--
Celso Providelo <celso.providelo@canonical.com>
IRC: cprov, Jabber: cprov@jabber.org, Skype: cprovidelo
1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-26-2008, 08:29 PM
"Celso Providelo"
 
Default Copy packages to same PPA, different distro

On Mon, May 26, 2008 at 10:11 PM, Pau Garcia i Quiles
<pgquiles@elpauer.org> wrote:
> Quoting Celso Providelo <celso.providelo@gmail.com>:
>
> [...]
>>>
>>> - Automatically copying packages between two PPAs. For instance, for
>>> Zumastor we have two PPAs, zumastor-team and zumastor-releases. Everytime
>>> a
>>> svn commit is done to the Zumastor repository, a package is built and
>>> published to the zumastor-team PPA. On the other hand, only the stable
>>> releases are published to the zumastor-releases PPA (ATM, manually copied
>>> from zumastor-team). Automating this would make life easier.
>>
>> Interesting setup, it seems to be the adopted pattern for all
>> Product-related PPAs, development & release.
>>
>> Are you imagining something kind of programmatic way to trigger the
>> copies once you are happy with QA ? a API ?
>
> I've forward this e-mail to Will Nowak, who is in charge of the script which
> automates package building of Zumastor. He knows better than me. One thing
> he'd surely like to have is an RSS feed of the packages a PPA publishes
> (currently for Zumastor we are scraping).

RSS feeds would be a great improvement.

>>> - Automatically building a package for more than one release (in the same
>>> PPA or in a different one). For instance, I may want to build my package
>>> for
>>> Gutsy, Hardy and Intrepid. ATM, either I manually copy the package (which
>>> does not work) or I upload the source three times (which is a PITA)
>>
>> Right, propagating source & binaries once they are built ...
>>
>> That's indeed a good idea. Can you file a bug about it, please ?
>
> I've filed bug #235064. This could be as easy as supporting the Debian
> Policy as stated in
> http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog (it
> says you can specify several distro releases in the debian/changelog file)

Good catch, thank you.

[]
--
Celso Providelo <celso.providelo@canonical.com>
IRC: cprov, Jabber: cprov@jabber.org, Skype: cprovidelo
1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-26-2008, 09:35 PM
Dan
 
Default Copy packages to same PPA, different distro

> > 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

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-27-2008, 09:23 PM
Michael Bienia
 
Default Copy packages to same PPA, different distro

On 2008-05-26 21:59:02 +0200, Pau Garcia i Quiles wrote:
> Not necessarily. If I build for Gutsy but the library breaks ABI
> compatibility in Hardy, the Gutsy binary won't work in Hardy (and of
> course the Hardy binary won't work on Gutsy, either).

If the ABI of a library changes then it must get a new package name to
make sure that upgrades work. Without the renaming you would get the
problem you describe.

If you try to install in such case the deb from Gutsy on Hardy, it will
fail due to unmet/broken dependencies.

Michael

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-27-2008, 10:12 PM
"Celso Providelo"
 
Default Copy packages to same PPA, different distro

On Mon, May 26, 2008 at 11:35 PM, Dan <danmbox@gmail.com> 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@canonical.com>
IRC: cprov, Jabber: cprov@jabber.org, Skype: cprovidelo
1024D/681B6469 C858 2652 1A6E F6A6 037B B3F7 9FF2 583E 681B 6469

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 05-27-2008, 10:29 PM
Pau Garcia i Quiles
 
Default Copy packages to same PPA, different distro

Quoting Michael Bienia <michael@vorlon.ping.de>:

> On 2008-05-26 21:59:02 +0200, Pau Garcia i Quiles wrote:
>> Not necessarily. If I build for Gutsy but the library breaks ABI
>> compatibility in Hardy, the Gutsy binary won't work in Hardy (and of
>> course the Hardy binary won't work on Gutsy, either).
>
> If the ABI of a library changes then it must get a new package name to
> make sure that upgrades work. Without the renaming you would get the
> problem you describe.
>
> If you try to install in such case the deb from Gutsy on Hardy, it will
> fail due to unmet/broken dependencies.

You are only partially right. If the ABI changes you should increase
the soversion, not rename the package. Changing the package name
should only be done if upstream or the Debian package is so broken
that increasing the soversion is impossible.

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#upstreamconcerns

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 

Thread Tools




All times are GMT. The time now is 06:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org