Bug#413987: Openjpeg updates
Paul "TBBle" Hampson wrote:
> Robin Cornelius wrote:
> > I have had a quick play with openjpeg today. On AMD64 i cannot run v1.2
> > i need SVN newer than v1.2 due to very nasty bugs. I have added a patch
> > to the dpatch system that brings version 1.2 upto SVN 465. I have also
> > rebased the other patches required on the Makefile (one was dropped as
> > its included in SVN). The so name is not quite right i *think* it should
> > be 1.2.0.so.2 which is what i have it as now in the debian source.
>
> Hmm. Where'd you get this numbering scheme from? A brief check of
> the libs on my system suggests that libthing.so.major.minor is
> normal for the actual shared library, ldconfig will create
> libthing.so.major, and the -dev package has a link from libthing.so
> to libthing.so.major.
Hi Paul,
I think the soname is 2 according to the the openjpeg makefile but the rest
of it I may have just got wrong. I will probably just remove this patch.
>
> (Note that Debian policy requires the libthing.so.major link to be
> provided in the package as the library may be needed before ldconfig
> has been run)
>
> Also, that's not the soname. The soname is libthing.so.major.
>
> Have you seen dancer's shared library packaging guide? I don't think
> he dictates a name for the actual library, but the links libthing.so
> and libthing.so.major are important to the Linux shared library loader.
It was following a debian guide that got me in this mess. Saying that
digits before
the .so can be used for version control but digits after the so reflect
the binary/API
compatability.
>
> I think it's best to reserve digits before the .so for API bumps
> where the old API version is still under
> development/maintenance/usage, ie. it would need a distinct -dev
> package.
>
> The only other numbering scheme I've seen, which is what upstream
> uses before my dpatch, is libthing-major.minor.so. This would also
> be fine, since ldconfig again can produce libthing.so.major, since
> ldconfig doesn't use the _name_ of the file to determine that name,
> but the -soname parameter to the linker. (See the upstream Makefile)
Probably a plan to leave it well alone and remove my patch. Infact
upstream in
the SVN i believe are using the same scheme that you had in your dpatch.
Best
leave upstream alone in this instance and if it is wrong it can be
picked up later
>
> Out of curiosity, why are all your patches numbered 00?
They are still justs tests. I will move them to a correct number when i
am happy.
>
> A quick look at the .diff.gz file shows the following files have
> been left lying around outside the debian/ directory:
> openjpeg_svn_475.patch
> patches/series
> .pc/.version
>
> (That last one might need to be added to a clean rule... I'm
> guessing pkg-config has left it lying around)
>
> It also looks like I left the 'debian/tm' file lying around,
> better remove that in your next build.
Ok i will update them when i look at it next.
>
> Feel free to take over maintainership of this package if you
> wish, or if you want to hook up a mailing list for maintainership
> and make yourself an Uploader, I'm good with that too.
>
I think a mailing list for maintainership sounds like a good plan.
I have also set up an apt repository for testing this stuff. That you
are free to use
(or anyone else following this and related secondlife bugs)
deb http://cornelius.demon.co.uk/apt/ unstable main
deb-src http://cornelius.demon.co.uk/apt/ unstable main
There is (will be) a ftp upload for this too. I will send you access
details direct via
encrypted GPG mail, but you can just dput or dupload to it. It would be
great we can
get some PPC debs there as well.
Regards
Robin
--
Dr Robin Cornelius
Design Engineer
Hirst Magnetic Instruments Ltd
(UK Magnetics Society management committee member)
Tel: +44 (0) 1326 372734 www.hirst-magnetics.com
Fax: +44 (0) 1326 378069 www.gaussmeter.co.uk
Tesla House, Tregoniggie Industrial Estate
Falmouth, Cornwall, TR11 4SN, U.K.
Reg No: 1564814 England
VAT Registered: GB730 0277 74
Reply to: