[Pkg-zfsonlinux-devel] Bug#686447: [RFC] First release of spl-dkms and zfs-linux packages for Debian

[Darik Horn]

On Fri, Feb 15, 2013 at 5:18 PM, Carlos Alberto Lopez Perez
<clopez at igalia.com> wrote:
> I'm only randomizing it when the current host's hostid is "0xffffffff",
> which I understand is an invalid hostid for ZFS and would case it to
> stop working properly. Isn't this the case?

Where I used 0xFFFFFFFF earlier, it was used as a canary value so that
an interrupted installation would fail gracefully.

Given that hostid() deterministically generates a value when the
/etc/hostid file is missing, this line 60 in the spl-dkms.postinst is
still suspect:

  dd if=/dev/urandom bs=1 count=3 seek=1 of=/etc/hostid 2>/dev/null

My concern here is that changing the return of hostid() can break
third-party software.  (eg: FLEXlm.)


>> The pristine-tar branch already exists in pkg-spl and pkg-zfs.  Using
>> the pristine-tar facility is certainly correct, but not currently
>> practical for doing the frequent releases that ZoL users expect.
>
> We should agree on a common way of working.
>
> Either we use pristine-tar or not.

Lets use pristine-tar then.


>> This breaks backports for Lucid (and its derivatives) because
>> dh-autoreconf is a non-main package on those systems.  Keeping
>> compatibility with all officially supported Ubuntu variants is
>> worthwhile and something that I want to do.
>>
>>
>
> Well. I love to have things as clean and small as possible.
> dh_autoreconf helps with that. But I understand your point. Not big deal.

I intend to cease Lucid builds when it goes out of extended desktop
support this April, so this issue will soon be mooted.


> github redirector is not longer needed, so why use it?
>
> http://wiki.debian.org/debian/watch?action=diff&rev2=10&rev1=9
>
> Also the url on the debian/watch on your packages is not working.

Okay, it is obsolete.


>> Modifying or omitting Oracle legal notices will attract Oracle
>> lawyers.  Saving less than 64 kilobytes of boilerplate per
>> installation is just not worth the risk.
>>
>>
> Ok.

Thanks. This is a relief.


>> This reintroduces a dkms ordering bug where the zfs build races the
>> spl build.  Notice how the BUILD_DEPENDS directive is handled by dkms.
>>
>>
>
> Is that a bug on dkms?

This is more of an enhancement than a bug.

Lustre, ZFS, and SPL are all separate projects upstream.  No other
Linux modules have such build dependencies outside of the packaging
subsystem.


> was reported?

Yes.

Note that zfsonlinux/dkms has a recent bug fix that has not yet been
submitted upstream.


> I don't agree in this.
>
> Shipping a commented file in /etc/sudoers.d will only cause trouble when
> the package is upgraded and tries to overwrite your local changes.
>
> The right place for such file would be  /usr/share/doc/$package/examples/

Okay, that is a fair substitute.


>> I added this kind of nagging to some private builds and got negative
>> feedback. YMMV. Consider disabling second-class architectures entirely
>> because Debian publishes updates very slowly between major releases.
>>
>
> IMHO enabling second-class architectures (non-x86) is a goal to achieve.
> It would help to find bugs on the codebase.

ZFS depends on assumptions about the Linux vmalloc that are false for
32-bit kernels.  It is worth noting that ARM support in ZoL is
arguably better than 32-bit x86 support.


> Debian publishes updates very slowly between major releases? I don't
> understand what you mean with this.

It sounded like there was an effort to get ZoL into Wheezy.  Any
version of ZoL that gets into a stable Debian release will have a very
long lifetime, and it is likely that upstream will improve 32-bit
support in the meantime.


> The warning is only show once. Once you have accepted it, it won't show
> anymore whenever you upgrade or reinstall.
>
>
> I understand that this could be annoying, but this is exactly for what's
> intended. Better annoy people when they install the package for the firs
> time, that let them run this without knowing that it could cause data
> corruption or instability on their systems on the long term.

Okay, this is ultimately an issue of aesthetics, so I will defer.


> PS: Darik, subscribe yourself to
> pkg-zfsonlinux-devel at lists.alioth.debian.org if you are not already.

I am subscribed.

TTYS.

-- 
Darik Horn <dajhorn at vanadac.com>