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

[Dimitri John Ledkov]

On 2 March 2014 16:05, Steven Chamberlain <steven at pyro.eu.org> wrote:
> On 02/03/14 12:19, Turbo Fredriksson wrote:
>> Might I suggest that the reason is that these is _completely_ different implementation, with
>> absolutly no common code?
>
> Right, so conversely, zfs-linux shares a lot of code already with
> zfsutils and it makes no sense for them to be packaged separately or
> compete over namespace?
>

I think it makes sense for myself to go through the differences and
propose packaging changes for Robert to review, to simply enable
linux-any targets in the existing zfs packages. This thus avoids the
packaging conflict all-together, but does impose compatability (e.g.
such that end-user binaries have compatible commandline interface,
flags, and operations - clearly different zfs api levels / options
will be supports, but the common base set should work the same across
all supported kernels).

If patches are intrusive, then conditionally applying the patches on
linux-any might work (as many other profilic packages do - binutils,
gcc, etc.)

>> if the FTP maintainers [...] 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.
>
>> Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this
>> moment.
>
> It actually seemed to be an offer for collaboration with you, but I
> don't see that working so well now.
>

No ftp-masters decisions are not laws - rejects usually only happen
after contacting the developer, inquiring unclear technical points and
mitigating the problems. Quite often, if it's possible to fix, things
are reuploaded.

it's simply their archive you ask inclusion into and they are free to
include things or not and tell you why =)))

The maintainer of a package, ultimately has the power to veto what
goes into the packages they are maintaining. If you are not sure what
or who a maintainer is, here is reference to the policy you are so
after https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
Current maintainers and uploads of zfsutils are listed at
http://packages.qa.debian.org/z/zfsutils.html

Debian welcomes all contributions by everyone, as long as one
constructively interacts with Debian. (If you want a reference, here
you go https://www.debian.org/intro/diversity )

Since you acknowledge the code differences are small, can you refactor
zfsutils required portions as patch series to existing zfsutils
package (and hence the related libraries, utils and udebs) ? That
would be ultimately easier to maintain, and will go quicker through
NEW queue, as it's only the utils and not the kernel module.

And then kernel dkms module can go through as a separate package.

Not sure if it at all makes sense to ship -dkms module out of the
zfsutils package, as I'm expecting linux dkms module to move at a
faster pace than the utils.

Would that work you?

-- 
Regards,

Dimitri.