[Debtags-devel] Re: First packaging issue for the new comaintainance team

[Torsten Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Enrico Zini schrieb:
> On Mon, Sep 12, 2005 at 02:07:03PM +0200, Simon Richter wrote:
> 
>>Enrico Zini wrote:
> 
> 
>>>- build -fPIC libraries again (and in that case I'd like to find a
>>>  better way to do it than before[1]
>>
>>In the long run, libtool could be kicked into doing that sanely. It has 
>>one disadvantage though: New code will not be tested, as the plugins are 
>>still using the old code, and it will be difficult to tell which version 
>>is being run.
> 
> 
> I don't mind too much about that: at the current state, we can easily
> track rdepends and be in touch with the maintainers.
> 
> 
>>>- build a .so and change its name at every upload
>>
>>Preferable IMO. It makes pretty much clear that this is an unstable API, 
>>but has the disadvantage of requiring rebuilds of all applications that 
>>use it (but this can be fixed by NMUing unchanged source with the 
>>permission of the respective maintainer)
> 
> 
> More interesting feedback from a #debian-tech[1] conversation on IRC:
> 
> 14:05 < enrico> I might have a question for this channel re
> http://lists.alioth.debian.org/pipermail/debtags-devel/2005-September/000821.html : do we have a proper recommended procedure to handle that case?
> 14:06 < enrico> I can see two ways: one is creating the -pic library (but
>                 there's no direct support on libtool to do that) and the other
>                 is changing soname at every upload (putting more load on the
>                 ftpmasters)
> 14:09 < vorlon> enrico: Policy 10.2 allows for creating a special _pic.a lib
>                 that's static but PIC.
> 14:18 < enrico> vorlon: is there an explicit note about it?  I couldn't find it
> 14:20 < vorlon> hmm... I can't find one
> 14:21 < vorlon> but see xlibs-static-pic for an example of a package that's
>                 done this for years
> 14:21 < enrico> vorlon: ok, thanks
> 14:22 < vorlon> sure
> 14:22 < vorlon> so I guess the answer is, policy doesn't actually allow it, but
>                 Policy is wrong. :)
> 14:22  * enrico is depressed at the burden of going back to make the -pic, but
>           at least now I have a couple comaintainers
> 14:22 < vorlon> why was the pic dropped?
> 14:23 < enrico> vorlon: because I wrongly understood it was only a performance
>                 issue and I could do without
> 
> 
> 
>>>The good news this time is that I'm not alone anymore in solving this
>>>mess and we can work it out in a team.  What do you think of this
>>>situation?
>>
>>Not sanely solvable until my autobuilder project is finished and/or 
>>packages that are uninstallable but buildable are automatically rebuilt.
> 
> 
> Gah, uhm... so let's stay in the sanely solvable and let's solve it in
> the less possible insane way :)
> 
> So far I could be happy with the -pic thing, especially if you have more
> libtool know-how than me to get this done in a saner way.

Hi,

I'd prefer the package split over changing soname over and over again and
introducing new packages every week. However, we have to rebuild all depending
packages for every new version, but this holds true for both solutions. Either
the library soname has changed or the new static PIC has to be linked in. In
both cases, the source of the depending packages might have to be changed
anyway. How many packages/maintainers are we speaking of? Are all the
maintainers reading that list? The language bindings are maintained by us as
well, aren't they?

greetings

Torsten
- --
Torsten Marek <shlomme at gmx.net>
ID: A244C858 -- FP: 1902 0002 5DFC 856B F146  894C 7CC5 451E A244 C858
Keyserver: subkeys.pgp.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDJco0fMVFHqJEyFgRAqo4AJ0ZRi6zt30qYcntunL4N2egOEVfZACfVMOs
00k5N4tsDudxtn/Mjn9zjZ4=
=GTQM
-----END PGP SIGNATURE-----