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

[Aron Xu]

[Cutting down the long CC list...]

On Sat, Feb 16, 2013 at 12:58 PM, Darik Horn <dajhorn at vanadac.com> wrote:
> 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.)
>

Once I found that Fedora's ZoL packaging uses static /etc/hostid, but
I wonder how it is handled in Solaris/illumos and BSDs?

>
>
>>> 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.
>

I agree to drop support for Lucid soon, keeping compatibility for too
much versions will cost great efforts.

>
>>> 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.
>

Yes, we indeed need to be very conservative in licensing since it's Oracle...

>
>
>>> 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.
>

I see no effort for Wheezy... All existing work are for experimental,
and we will first upload to Sid when 0.6.1 is out. This is again
conservative, and because of the value of data I believe it's worthy.

>
>> 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.
>

I've read quite some of issues in upstream issue tracker, and it seems
that i386 support is keep moving, though current status isn't very
optimistic. Shall we create a whitelist/blacklist of architectures for
such warnings?


--
Regards,
Aron Xu