Debian packaging code is mixed with ZoL source code

[danielkza]

I'm trying to update the Debian packagin to the upstream changes in ZoL (new libzfs and libzpool versions, creation of libzfs_core, etc), and the fact that the source code is copied into the branches is causing me some headache.

git-buildpackage knows how to check out source from tags and create the source tarballs from it, which means you can have a branch containing only debian resources, and pull a secondary, clean branch directly from upstream and have everything neatly separated.

I believe it would be a good idea to create a separate branch only for the debian packaging configuration, and build up the release branches from it.

[FransUrbo]

These tags are for official releases, to make absolutly sure that who ever do the build (so that all of us can be replaced :), gets a package that's identical to the one released.

These repositories isn't really intended for general consumption, but for the ZoL package maintainers so that we can have a history on things we do and what is actually released. Anyone that wants latest-and-greatest based on official sources, needs to do the homework and merge and kludge it themselves.

EVENTUALLY, one day when I have to much free time, I'll see if I can arrange a 'daily snapshot package builds' and then this will be moot.

So this will not be fixed.

[danielkza]

Having the clean debian branch even in addition to the mixed branches would already be very helpful, specially for people wanting to test current snapshot, and a good way to centralize build procedure and changes between Ubuntu and Debian.

[FransUrbo]

That is for software that isn't made by Debian GNU/Linux. For those packages, the debian directory is included with the code that was used. Look at debootstrap as an example - no separation between code and debian packaging... This is what these tags/branches is.

Again, those tags/branches isn't intended for everyone. Those are intended for ME (or whoever replaces me as official ZoL Debian GNU/Linux package maintainer).

I could just as well delete them from ZoL repository and move them to my own GitHub account. But that would complicate things for my replacement...

PREFERABLY, a debian directory should be included in the ZoL zfs repository (see openzfs/zfs#1713), but that was rejected.

If you really, really feel strongly about this, then take it to ZoL.

[danielkza]

I understand, I was just a bit frustrated due to all the repeated mergers and conflict fixes I had to do to get a current build rolling. If you prefer to keep things merged then I don't have a problem with it.

I have to say though, that as a user that having access to nightly builds and/or being able to easily compile them myself helps a lot when trying to help in fixing/testing bugs, and is a good way to be sure you're not breaking anything accidentally only to realize it later on.

Anyway, I'll send a pull request soon for some build updates that allow building the current master for wheezy, and hopefully 0.6.3 when the ZoL folks decide to release it.

[FransUrbo]

Thanx, and I DO understand the frustration, I'm not completely cold-hearted :).

But anyone that want to stay with the latest-and-greatest is better of using the ZoL code repositories (for now) and use the debs that are/can be built there. They are as close to proper debs that one could get. Perfectly good enough in any case.

If you have lots of time on your hand and want to help making daily snapshot debs a reality, have a look at the README.md (Release Instructions - the part related to s3cmd and reprepro) and figure out how to keep all versions installable - a daily snapshot should NOT automatically replace the officially released version when doing a apt-get upgrade.
The snapshots in itself should be kept in the repository for posterity (as in: not removed by reprepro include, which is the default).

[danielkza]

The reason I'm not using them is the lack of DKMS, since I'm looking into running a system with a backported 3.12 kernel, which 0.6.2 does not support.

[FransUrbo]

I meant the https://github.com/zfsonlinux/zfs and https://github.com/zfsonlinux/spl repositories... Besides, DKMS sucks! Better to have the kmod-{spl,zfs}... package for the kernel you're running.

[danielkza]

I checked out the upstream debs and I can't get grub support with them, and I planned to have a ZFS root :(

[FransUrbo]

Have a look at:

openzfs/zfs#2087
openzfs/zfs#2106

[danielkza]

Are the initramfs changes enough for booting with a ZFS root? So the GRUB package is superfluous after all?

[FransUrbo]

You need the initramfs changes to create an initrd with zfs support. They where part of the zfs-initramfs (from pkg-zfs repo). You still need grub a grub that understands zfs to boot into it and retrieve the initrd :)

[danielkza]

The GRUB packages depend o libzfs1 from your repo, but upstream generates one single 'zfs' package containing libzfs.so.2, and is not tagged as providing libzfs.

Since I have an ext2 boot partition I'll try setting up the initramfs in it and see how far I can get.

[FransUrbo]

Ok, perfect for reporting this. Thanx!

See zfsonlinux/grub#8.

[danielkza]

Just want to report that I'm back to a successfully working ZFS root on kernel 3.12 with your initramfs scripts and an ext2 boot partition, with debian's stock GRUB.

[FransUrbo]

Perfect, thanx. Oh, I should have said that a ZFS aware grub is only needed if your initrd and kernel is on ZFS... Since your's not, you're good with the stock grub...