search

coin3d / simage

Image file loading
ISC License
7 stars 9 forks source link

feedback on packaging simage 1.8.0 #30

Closed yopito closed 3 years ago

yopito commented 4 years ago

I try to package simage 1.8.0 for the VoidLinux distribution.
Here some points I've noticed and some questions:

  1. does github.com is the official new home for simage ?

  2. simage 1.8.0 has been officially released and does https://github.com/coin3d/simage/archive/simage-1.8.0.tar.gz is the official source tarball ?

  3. 1.8.0 source tarball has twice "simage" in the folder name: simage-simage-1.8.0/

  4. 1.8.0 source tarball does not provide cpack.d/ subfolder, although it's required in CMakeLists.txt : had to patch CMakeLists.txt to get rid off it

  5. builds via configure and via cmake produces libs that don't have the same numbering, and cmake numbering is non-consistent: 

    (configure) /usr/lib/libsimage.so.20 -> /usr/lib/libsimage.so.20.7.1
(configure) /usr/lib/libsimage.so.20.7.1

(cmake)     /usr/lib/libsimage.so.20 -> /usr/lib/libsimage.so.1.8.0
(cmake)     /usr/lib/libsimage.so.1.8.0

    Cheers

VolkerEnderlein commented 4 years ago

We are just in the middle of moving the entire repo over to GitHub. This will be the new home for Coin3D since BitBucket is sunsetting Mercurial support in near future. As we do not have been finished the migration part up to now I ask for some patience. See this thread for the current state.

According to your questions

  1. Yes!
  2. This is right. If the migration is properly finished you'll find the source tarball under this address.
  3. This is caused by the automatic import of the Mercurial tags (we chose simage-1.8.0 as tag name) and will be corrected soon by a v1.8.0 tag.
  4. This is also caused by the import process. The initial import is not fully functional up to now. This is currently being worked on and will be finished soon.
  5. The release has been done on the Mercurial repo before starting the migration, it seems the version information has not been properly updated there. Thanks for catching this :)

Cheers

yopito commented 4 years ago

thanks for your explanations and all my wishes for the migrations.
Do you want dedicated issues for point 3, 4 and 5 ?

Regarding source tarball : you plan to regenerate a new 1.8.0 one, and not create a new release like 1.8.0.1 or 1.8.1 ? So the 1.8.0 listed above is not yet the "real" release ? Not having immutable release and source make packaging difficult : fingerprint of source tarball become impossible for instance.

Edit: avoid github rendering with "#<number>"

VolkerEnderlein commented 4 years ago

Thanks for your response.

We use submodules all over the repositories so the automatically provided source tarballs are not fully functional. You need the git information to update the submodules.

If you need to continue with the packaging for version 1.8.0, I would propose using the Mercurial tarballs/zips from the old bitbucket repo. They should be fully functional and will be stored under a separate Git repository here on Bitbucket that hopefully will not be touched by Atlassian. The released simage source tarballs/zips can be found here. I have only automatically prepared the zip file versions of the sources. On GitHub we will automatically provide the tar.gz versions too.

I do not think you need to create separate issues for those tasks as they are migration related. I fixed some of them already but tagging has not been done until now.

That's a good point. Tagging 1.8.0 has been done on Mercurial, but the tarballs were not released properly . We will release a 1.8.1 version that fixes the issues with source tarballs and versioning when migration has properly done.

VolkerEnderlein commented 3 years ago

I am just about to tag the simage 1.8.1 version that should address all the issues from your report. Can you test the current state of the repository in your environment? That would be an enormous help. Cheers

yopito commented 3 years ago

yes, no problem (and closed issue by mistake)

yopito commented 3 years ago

summary (in progress):

Edit: describe build env (voidlinux, gcc, etc)

yopito commented 3 years ago

complete list of installed files (if needed):

/usr/bin/simage-config
/usr/lib/libsimage.so.1.8.1
/usr/lib/libsimage.so.20 -> /usr/lib/libsimage.so.1.8.1
/usr/share/Coin/conf/simage-default.cfg
( /usr/share/licenses/simage/LICENSE )
# in my -devel package
/usr/include/simage.h
/usr/lib/cmake/simage-1.8.1/simage-config-version.cmake
/usr/lib/cmake/simage-1.8.1/simage-config.cmake
/usr/lib/cmake/simage-1.8.1/simage-export-release.cmake
/usr/lib/cmake/simage-1.8.1/simage-export.cmake
/usr/lib/libsimage.so -> /usr/lib/libsimage.so.20
/usr/lib/pkgconfig/simage.pc
VolkerEnderlein commented 3 years ago

Thanks so much for taking the time to test current repository state. I am just examining what lead to the different .so.x.y.z numbering. According to the simage-config and simage-default.cfg files: I was under the impression that they are needed when using the pkg-config .pc file, as some people requested it for a seamless migration to the current version. But my knowledge of this is very limited and is only slowly improving as I am mostly using the CMake stuff.

Update: Wrong ABI version on .so link was fixed by commit d00da9c73972995df953ceaafc563efd88e61bcc

yopito commented 3 years ago

To provide "legacy" pkg-config support, .pc files are needed indeed. Might be generated via cmake too. I will test your soname bump fix asap.

yopito commented 3 years ago

built with d00da9c (fine). generated files for lib (other files remain the same):

/usr/lib/libsimage.so -> /usr/lib/libsimage.so.20
/usr/lib/libsimage.so.20 -> /usr/lib/libsimage.so.20.8.1
/usr/lib/libsimage.so.20.8.1
VolkerEnderlein commented 3 years ago

Thank you again many times for your highly appreciated support. I just released simage patch version v1.8.1.

reavertm commented 3 years ago

Good job on getting rid of automagic dependencies with https://github.com/coin3d/simage/commit/f8fa2027019b93d76f8a846a6dfbd5e8363e0f14, helps with uncovering build issues a lot. I think only https://github.com/coin3d/simage/blob/master/CMakeLists.txt#L129 (and maybe some Windows specific dependecies above) remains to have REQUIRED added to be ideal.

VolkerEnderlein commented 3 years ago

@reavertm Has just been committed. Thanks for the feedback.