On 2 March 2014 16:05, Steven Chamberlain <ste...@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. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUh4ij6cN-qBp=U8MF-DSVP5iZmf-gLQBfm=y8bexqq...@mail.gmail.com
