Page MenuHomeFreeBSD

multimedia/assimp: Update to 4.1.0
ClosedPublic

Authored by yuri on Feb 7 2018, 8:26 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Mar 12, 9:52 AM
Unknown Object (File)
Tue, Mar 12, 9:52 AM
Unknown Object (File)
Tue, Mar 12, 9:52 AM
Unknown Object (File)
Tue, Mar 12, 9:52 AM
Unknown Object (File)
Tue, Mar 12, 9:52 AM
Unknown Object (File)
Tue, Mar 12, 9:40 AM
Unknown Object (File)
Sat, Mar 2, 2:37 AM
Unknown Object (File)
Jan 14 2024, 5:28 PM
Subscribers

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
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 14867
Build 14980: arc lint + arc unit

Event Timeline

multimedia/assimp/Makefile
22

^ CMAKE_OFF=ASSIMP_BUILD_TEST

28–29

^ 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 marked 3 inline comments as done.

.

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
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
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.

Why do you bump those three ports ?

In D14253#299253, @mat wrote:

Why do you bump those three ports ?

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

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.

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?

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).

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.

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.

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.

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.