We've a complex versioning scenario here which leads me to my limits. :(
There are two recipes. One for a shared library and one for an application
using this library.
Both use GNU autotools (so they have internal version information). For
continuous integration purposes both use AUTOREV.
At t
On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote:
> We've a complex versioning scenario here which leads me to my limits. :(
>
> There are two recipes. One for a shared library and one for an application
> using this library.
>
> Both use GNU autotools (so they have internal version inform
On 24.03.2014 13:35, Richard Purdie wrote:
> On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote:
>> We've a complex versioning scenario here which leads me to my limits. :(
>>
>> There are two recipes. One for a shared library and one for an application
>> using this library.
>>
>> Both use GN
On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote:
> On 24.03.2014 13:35, Richard Purdie wrote:
> > On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote:
> >> We've a complex versioning scenario here which leads me to my limits. :(
> >>
> >> There are two recipes. One for a shared library an
On 24.03.2014 13:53, Richard Purdie wrote:
> On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote:
>> On 24.03.2014 13:35, Richard Purdie wrote:
>>> On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote:
We've a complex versioning scenario here which leads me to my limits. :(
Ther
On Mon, 2014-03-24 at 15:22 +0100, Steffen Sledz wrote:
> On 24.03.2014 13:53, Richard Purdie wrote:
> > On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote:
> >> On 24.03.2014 13:35, Richard Purdie wrote:
> >>> On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote:
> > debian.bbclass (debian p
On Mon, Mar 24, 2014 at 03:22:35PM +0100, Steffen Sledz wrote:
> On 24.03.2014 13:53, Richard Purdie wrote:
> > On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote:
> >> On 24.03.2014 13:35, Richard Purdie wrote:
> >>> On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote:
> We've a comple
On Mon, Mar 24, 2014 at 5:16 AM, Steffen Sledz wrote:
> We've a complex versioning scenario here which leads me to my limits. :(
>
> There are two recipes. One for a shared library and one for an application
> using this library.
>
> Both use GNU autotools (so they have internal version informati
On 24.03.2014 16:15, Martin Jansa wrote:
> On Mon, Mar 24, 2014 at 03:22:35PM +0100, Steffen Sledz wrote:
>> On 24.03.2014 13:53, Richard Purdie wrote:
>>> On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote:
On 24.03.2014 13:35, Richard Purdie wrote:
> On Mon, 2014-03-24 at 13:16 +0100
On Tue, 2014-03-25 at 11:31 +0100, Steffen Sledz wrote:
> On 24.03.2014 16:15, Martin Jansa wrote:
> Thanx, this was the decisive hint.
>
> I've increased the version in the SONAME header of the library and the result
> is a libfoo1 package. :)
>
> But now i hit the next problem. The following r
On 3/25/14, 5:31 AM, Steffen Sledz wrote:
On 24.03.2014 16:15, Martin Jansa wrote:
On Mon, Mar 24, 2014 at 03:22:35PM +0100, Steffen Sledz wrote:
On 24.03.2014 13:53, Richard Purdie wrote:
On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote:
On 24.03.2014 13:35, Richard Purdie wrote:
On M
On 25.03.2014 16:03, Mark Hatle wrote:
> On 3/25/14, 5:31 AM, Steffen Sledz wrote:
>> On 24.03.2014 16:15, Martin Jansa wrote:
>>> On Mon, Mar 24, 2014 at 03:22:35PM +0100, Steffen Sledz wrote:
On 24.03.2014 13:53, Richard Purdie wrote:
> On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wr
On 07.04.2014 14:37, Steffen Sledz wrote:
> On 25.03.2014 16:03, Mark Hatle wrote:
>> ...
>> If the package 'requiring libfoo' has a DEPENDS += ... in it.. then yes, it
>> should have been rebuilt when the libfoo was rebuilt.
>
> Unfortunately i can't confirm that. :(
>
> part of the real app r
On Mon, 2014-04-07 at 15:22 +0200, Steffen Sledz wrote:
> On 07.04.2014 14:37, Steffen Sledz wrote:
> > On 25.03.2014 16:03, Mark Hatle wrote:
> >> ...
> >> If the package 'requiring libfoo' has a DEPENDS += ... in it.. then yes,
> >> it should have been rebuilt when the libfoo was rebuilt.
> >
>
On 07.04.2014 16:49, Richard Purdie wrote:
> On Mon, 2014-04-07 at 15:22 +0200, Steffen Sledz wrote:
>> On 07.04.2014 14:37, Steffen Sledz wrote:
>>> On 25.03.2014 16:03, Mark Hatle wrote:
...
If the package 'requiring libfoo' has a DEPENDS += ... in it.. then yes,
it should have be
On Tue, Apr 8, 2014 at 5:33 AM, Steffen Sledz wrote:
> If a package contains a shared library *and* a binary (e.g. a related command
> line tool) then the soname major version *is not appended* to the package
> name (see debian_package_name_hook in debian.bbclass). All other problems are
> afte
Am 08.04.2014 19:20, schrieb Khem Raj:
> On Tue, Apr 8, 2014 at 5:33 AM, Steffen Sledz wrote:
>> If a package contains a shared library *and* a binary (e.g. a related
>> command line tool) then the soname major version *is not appended* to the
>> package name (see debian_package_name_hook in deb
On Apr 8, 2014 8:58 AM, "Steffen Sledz" wrote:
>
> Am 08.04.2014 19:20, schrieb Khem Raj:
> > On Tue, Apr 8, 2014 at 5:33 AM, Steffen Sledz
wrote:
> >> If a package contains a shared library *and* a binary (e.g. a related
command line tool) then the soname major version *is not appended* to the
p
18 matches
Mail list logo
