[Bug 265651] [NEW PORT] archivers/zpaqfranz: versioned/snapshot archive

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265651

--- Comment #22 from Franco Corbelli <franco@francocorbelli.com> ---
(In reply to Felix Palmen from comment #21)

>It's not forbidden, but it's typically removed if there is no unavoidable 
>reason. 
>Remember, we're talking about managed packages here. No way required libs will 
>just disappear (except for a user going rogue as root, but that's not really a 
>concern). 

In reality, they always "disappear" (better: some dependency of some program
automatically uninstalls another program, which in turn had a specific version
etc)
Classic example: sphinx, mysqlclient and mariadb
But I wouldn't want to go too far, let's go back to zpaqfranz: I do not think
it is not the best choice, but if dynamic linking is good for you, is good for
me too

>- you can't control whether security fixes are really applied
Security fix for an archiver? And what kind can they be?
In reality, any malicious injection into a shared library affects "everyone",
even zpaqfranz, which does not need it at all
Similarly for bugs introduced (it often happens)
My philosophy is: as long as it works, leave it alone. Do not even touch.
Maybe it's different on "newer" FreeBSD
As always, there are costs and benefits in every choice.

>you lose reproducible builds when these libs are ever changed
It doesn't seem like a problem to me, but it's not important

>So, in this case here, I see no reason for static linking. 

OK, dynamic linking is definitely good

(...)
>Almost certainly, this wouldn't be accepted, and people would tell you "add a 
>symlink to your original port".
I will make (if I have to) a dedicated Delphi program which, from the zpaqfranz
source, will make the source dir.cpp, without all the useless portions
A couple of hours of work, a different software, a different port.

>Again, a  root user "going rogue" is not a relevant scenario.
It happens all the time :)
So much so that there is a specific trick in zpaqfranz also for this case

>This sounds like a port/package would be unsuitable for your software (...)
Don't confuse the "normal" user, the one using port or package, with the
"advanced" user.
The latter will download the latest version of the source with wget or even
git-something and compile it by hand (no make needed), linking statically :)
Or, maybe, it will write its very own zpaq++

> but not if every single version drops backwards compatibility ... 
> it can't grow forever.

Backward compatibility is ensured: it is a key element of my project.
I worked hard to "hack" the storage format of zpaq to save the CRC-32 and the
hash of each file, for SHA-1 collision detection, without the zpaq version
already in the port tree even noticing it.
Statically compiled executables can (and usually are) be launched directly with
their version name: they are independent
Remember: each is about 2MB in size, no configuration file, no dependencies

---
But let's not exaggerate, the "normal" user doesn't want much more than 
"make install clean" or "pkg install something"

My port proposal is for that "type" of user

Short version: dynamic linking OK

-- 
You are receiving this mail because:
You are the assignee for the bug.