Page MenuHomeFreeBSD

multimedia/assimp: Update to 4.1.0
ClosedPublic

Authored by yuri on Feb 7 2018, 8:26 PM.

Details

Summary

Simple update

Additional changes:

  • Deleted unnecessary static library libIrrXML.a

Bumped: games/pioneer games/doomsday graphics/qt5-3d

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

yuri created this revision.Feb 7 2018, 8:26 PM
tcberner added inline comments.Feb 8 2018, 12:18 AM
multimedia/assimp/Makefile
22 ↗(On Diff #39021)

^ CMAKE_OFF=ASSIMP_BUILD_TEST

28 ↗(On Diff #39021)

^ this possibly is no longer be needed (see last comment in the pr)

multimedia/assimp/files/patch-code_Q3BSPZipArchive.cpp
2 ↗(On Diff #39021)

upstream candidate?

yuri updated this revision to Diff 39032.Feb 8 2018, 3:54 AM
yuri marked 3 inline comments as done.

.

yuri added inline comments.Feb 8 2018, 3:54 AM
multimedia/assimp/files/patch-code_Q3BSPZipArchive.cpp
2 ↗(On Diff #39021)

Upstream already has both patches now. I didn't want to take the current revision because it might be unstable.

yuri marked an inline comment as done.Feb 8 2018, 3:54 AM

You lost the bumps

tcberner added inline comments.Feb 8 2018, 6:48 AM
multimedia/assimp/files/patch-code_Q3BSPZipArchive.cpp
2 ↗(On Diff #39021)

In that case, I would use directly
https://github.com/assimp/assimp/commit/096056b899d9c423cdcad527849126e3e3e17a34.patch
and call it patch-git_096056 or something like this :)

yuri marked an inline comment as done.Feb 8 2018, 7:19 AM
tcberner accepted this revision.Feb 8 2018, 8:23 PM
This revision is now accepted and ready to land.Feb 8 2018, 8:23 PM
This revision was automatically updated to reflect the committed changes.
mat added a comment.Feb 8 2018, 10:37 PM

Why do you bump those three ports ?

yuri added a comment.Feb 8 2018, 10:44 PM
In D14253#299253, @mat wrote:

Why do you bump those three ports ?

Because the shared library version has changed, and they depend on it.

mat added a comment.Feb 8 2018, 10:49 PM
In D14253#299259, @yuri wrote:
In D14253#299253, @mat wrote:

Why do you bump those three ports ?

Because the shared library version has changed, and they depend on it.

The library version does not change, it was 4 before, and it's SHL1 now, which is also 4.

yuri added a comment.Feb 8 2018, 10:59 PM
In D14253#299260, @mat wrote:

The library version does not change, it was 4 before, and it's SHL1 now, which is also 4.

I didn't realize that only the major version matters for bumps, not the whole version.
5.2.3.1. PORTREVISION says: "Version bump of a port's shared library dependency". It doesn't say "major version". Maybe 5.2.3.1 should be clarified?

mat added a comment.Feb 8 2018, 11:07 PM
In D14253#299263, @yuri wrote:
In D14253#299260, @mat wrote:

The library version does not change, it was 4 before, and it's SHL1 now, which is also 4.

I didn't realize that only the major version matters for bumps, not the whole version.
5.2.3.1. PORTREVISION says: "Version bump of a port's shared library dependency". It doesn't say "major version". Maybe 5.2.3.1 should be clarified?

You must bump when soname changes. Because then, the linker cannot find the library any more. Here, it does not change. (Or, if the soname is .4.1.0, the .4 symlink is useless.)

There is no such thing as a major/minor/foo version. Here, the soname is most likely libassimp.so.4 (you can find out what it is using readelf -d, for example.)

But for instance, with Perl 5, libperl's soname is libperl.so.5.24, for boost, it is libboost_atomic.so.1.66.0 (taking one library at random).

yuri added a comment.Feb 8 2018, 11:23 PM
In D14253#299264, @mat wrote:
In D14253#299263, @yuri wrote:
In D14253#299260, @mat wrote:

The library version does not change, it was 4 before, and it's SHL1 now, which is also 4.

I didn't realize that only the major version matters for bumps, not the whole version.
5.2.3.1. PORTREVISION says: "Version bump of a port's shared library dependency". It doesn't say "major version". Maybe 5.2.3.1 should be clarified?

You must bump when soname changes. Because then, the linker cannot find the library any more. Here, it does not change. (Or, if the soname is .4.1.0, the .4 symlink is useless.)
There is no such thing as a major/minor/foo version. Here, the soname is most likely libassimp.so.4 (you can find out what it is using readelf -d, for example.)
But for instance, with Perl 5, libperl's soname is libperl.so.5.24, for boost, it is libboost_atomic.so.1.66.0 (taking one library at random).

Yes, soname is libassimp.so.4 in this case.
But what happens when soname didn't change, but the library itself becomes incompatible between versions? For example, they might add an extra enum value that the older library version doesn't have.
In this case, their change log in particularly long. Some major changes might be there.

mat added a comment.Feb 8 2018, 11:29 PM

What I said is that you only have to bump when the soname change. I never said that you must not bump when the soname does not change.

Adding a new enum value would only break software built with the new library and somehow used with the old one, but not the other way around, it would simply be a case that software built with the old library do not know about, and cannot use.

Also, if the new software is really not compatible, then they should bump their version from 4 to 5, for example.

yuri added a comment.Feb 8 2018, 11:35 PM
In D14253#299274, @mat wrote:

What I said is that you only have to bump when the soname change. I never said that you must not bump when the soname does not change.
Adding a new enum value would only break software built with the new library and somehow used with the old one, but not the other way around, it would simply be a case that software built with the old library do not know about, and cannot use.
Also, if the new software is really not compatible, then they should bump their version from 4 to 5, for example.

Ok. So it sounds like it is safer to just always bump dependencies when the shared library changes? Because we usually really don't know what actually changed in shared libraries.

adamw added a comment.Feb 9 2018, 2:48 AM
In D14253#299275, @yuri wrote:

Ok. So it sounds like it is safer to just always bump dependencies when the shared library changes? Because we usually really don't know what actually changed in shared libraries.

No, only when the soname changes. It's a shared library, so rebuilding when the soname hasn't changed does literally nothing---it's still linked against the same file, expecting the same symbols. Nothing will change on the rebuilt package.

The point of the bump is for when the soname has changed, because then the binaries will be linked against a file that no longer exists. If the file still exists, a bump does nothing.