[Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?

[Turbo Fredriksson]

On Mar 2, 2014, at 12:05 PM, Robert Millan wrote:

> There's a reason we add a "freebsd-" prefix to functionally equivalent packages like:
> 
> freebsd-smbfs - mount command for the SMB/CIFS filesystem
> freebsd-net-tools - FreeBSD networking tools
> freebsd-nfs-common - NFS support files common to client and server
> freebsd-nfs-server - FreeBSD server utilities needed for NFS on GNU/kFreeBSD
> freebsd-ppp - FreeBSD Point-to-Point Protocol (PPP) userland daemon

Might I suggest that the reason is that these is _completely_ different implementation, with
absolutly no common code?

> Your repeated insistence on occupying the "zfsutils" namespace makes me think you have a self-serving reason for this.

Of course I have - I have never denied this. But the same can be said for you - you have shown an
extreme "ill will" against us using that name. One could only guess why...

My/our reasoning is that it is based on the same code (even if not the same source package - yet),
gives the same functionality, with the same... etc, etc.

I've said that a few times by now, if you don't want to understand that part, let's wait for the FTP
maintainers ruling.

> How do you plan to react when actual breakage happens?

Rename it.

It's just that easy. IF someone can actually show me that this is actually illegal and can point me
to a policy AND/OR if the FTP maintainers (which have the final say in this - not you, not me, not
any one else!) say that this is not acceptable, then we'll rename it, without any bitching or
whining or expressing opinions that we can't backup with facts.

For now, I have not heard one word about this from them. The only thing I've heard is that there
"might" be a problem with the licensing and that they want to investigate this properly and be absolutly sure - it is their job, the one they where elected and trusted to do.

Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this
moment.

Dimitri is the only one that have given something that is slightly more than just a personal opinion:

On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:

> Hostile binary takeover is not allowed - that is two separate source
> packages should not build the same binary package names, even if on
> different architectures.

This at least SOUNDS like something that could be a policy. You have not provided ANYTHING that can
be considered anything else than a personal opinion and "dislike/disdain" of the name.


I still want/need something that actually IS a policy. Until then, may I suggest we both table
further discussion about renaming the package until we get the FTP maintainers ruling on the package.
They have been Cc'd on this thread, so they will know that there "might" be a controversy in the
naming.

If they rule the license ok but the name wrong, they won't allow it into the archive as-is anyway, so
there is no danger in waiting and letting them do their job.


> Unless I missed something, ZoL is not OpenZFS.

No.... ? Where did you get/draw that conclusion from?

> And neither ZoL nor OpenZFS support the kernel of FreeBSD at the time of writing.

I can't say yes or no on that, I just don't know. I'm involved in ZoL, not OpenZFS. But it would
actually surprise me somewhat if it didn't. This because they, from what I understand (which might be
wrong) used the Illumos code as starting point. And, again from what I understand, is the code *BSD
is using.

But talking about what OpenZFS _IS_ and what it's _INTENDED_ to be is irrelevant at the moment. My
point have been that _eventually_, there won't BE a "FreeBSD/ZFS' or a "Linux/ZFS" version. There
will ONLY be OpenZFS!

And that is only partly irrelevant. In the sense that the current FreeBSD 'zfsutils' and the Linux
'zfsutils' is _basically_ the same, but still not _exactly_ the same....

> You make it look like you're adding a portable package

No I don't. I haven't even hinted to it..

> when in fact it is a Linux-specific package.

Yes. Have someone made you believe it to be something else?

> I think it would serve that agenda to imply that ZoL is OpenZFS and the source you're adding is
> portable, but I don't think you even believe what you're implying.

This is completely your complete misunderstanding and inability to read and understand what's been
said. You need to go back and read it again.

> If you truly believe in the "unification path"

I do. Whole heartedly - it's the only way forward into the future! Keeping X number of
implementations, sharing a huge part of the exact same code won't be sustainable in the long run (it
have already proved somewhat of a problem - both in ZoL and in Illumos).

> I notice that you ignored it on your reply to him:
> 
> On 02/03/2014 03:52, Dimitri John Ledkov wrote:
>> Also, if there is zfs-dkms module available, why existing zfsutils
>> packages just can't enable compilation on "linux-any"?! Which should
>> also reduce the scope of linux specific packages down to
>> -dkms/-initramfs, and maybe an arch specific patch-series.

I DID answer it:

On Mar 2, 2014, at 6:56 AM, Turbo Fredriksson wrote:

>> why existing zfsutils packages just can't enable compilation on "linux-any"?!
> 
> You said it yourself - they are different implementations. Yes, they share a lot (!!) of similar
> code, but they are also not compilable on their "opposite" arch. 


> Why don't you send patches for zfsutils to enable compilation on linux-any? I'll be happy to work
> with you.


Why would I do that?! That's what OpenZFS is intended for! If you like duplicating work and essentially waste time, feel free. But I'm not going to.

OpenZFS was started for this exact purpose - joining the code so that it could be compiled on
"anything/everything".
--
If something's hard to do, then it's not worth doing.
- Homer Simpson