Re: git: 0d316feccaf8 - main - sysutils/cpdup-FreeBSD: Add FreeBSD fork of cpdup

On Wed, Feb 26, 2025 at 04:17:19PM +0100, Guido Falsi wrote:
> On 26/02/25 16:00, Alexey Dokuchaev wrote:
> > On Wed, Feb 26, 2025 at 08:41:49AM +0100, Guido Falsi wrote:
> > > On 26/02/25 05:02, Alexey Dokuchaev wrote:
> > > > On Tue, Feb 25, 2025 at 10:00:19PM +0000, Guido Falsi wrote:
> > > > > commit 0d316feccaf89c1bd804d6001274426a7135c93a
> > > > > 
> > > > >     sysutils/cpdup-FreeBSD: Add FreeBSD fork of cpdup
> > > > > 
> > > > >     Add a fork of cpdup, including patches to support copy_file_range(2)
> > > > >     and allowing to choose checksum algorithm.
> > > > 
> > > > Any reason not to add this to the `sysutils/cpdup' itself?  If there are
> > > > fears it might break something or be not fit for other reasons, it can be
> > > > hidden under option.
> > > 
> > > These are actually separate projects at this point, users should be well
> > > aware they are using a fork and able to choose which one to use.
> > 
> > Okay, but then the fork's name is poorly chosen: as a FreeBSD user I'd be
> > rather confused as to why there are two FreeBSD ports, similarly named but
> > one has explicit -FreeBSD suffix (note that this is quite unconventional
> > on its own, not to mention the port/package name uglification it entails).
> 
> MM submitted patches upstream quite some time ago. These have been sitting
> there. At some point a new forked repo has been created in the FreeBSD
> github account, including these patches.

Noted.

> > Well, the *name* is actually the same.
> 
> The name of the executable is the same,. because there is no breaking change
> in the interface (well except the addition of choosing the hashing
> algorithm, but if using md5 everything should stay compatible), so it is a
> drop in replacement.
> 
> The repository is in a different "company" on github and renaming that would
> have been redundant, and difficult.
> 
> If you want to suggest more changes to our forked repo to differentiate it
> from the origin please do

No, no, you've explained the situation well enough, I don't think I'm in
position to add anything more sensible ATM.  I just didn't like the new
port name. :-)

> but changing the name of the executable would not make much sense at present.

Agreed.

> > Oh, I see, so it's fucked up on all sides, not just ours.  Let's hope both
> > upstreams, DragonFly's and ours, can sort this out so we don't have to keep
> > two pretty much identical ports in the tree. :-/
> 
> All the patches in out fork have already been submitted to the upstream
> repo, but never accepted.

I see, thanks for elaborate explanation Guido.

./danfe