[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux



On 06.05.2012 10:16, Dmitry Smirnov wrote:
> On Sun, 6 May 2012 15:24:10 Michael Tokarev wrote:
>> And note that whole 5.0.6-allow-for-kernel-packet-size-change.patch
>> is NOT NEEDED, it should be reverted upstream.  *SIGH*, we spent
>> a ton of time and emails discussing this matter, please find
>> the recent LWN feature article about it (a good summary), or
>> LKML threads.  The patches are now added to all stable trees.
>>
>> The two patches -- linux kernel version check and this one --
>> should be reverted upstream and not included in debian package.
> 
> Thanks for this, I trust you that we don't need 
>     5.0.6-allow-for-kernel-packet-size-change.patch
> 
> However it is not too easy to just drop this patch because it will break the 
> chain of upstream patches. Possibly we need to apply all upstream patches and 
> then use our new patch to revert some of their changes... Or maybe consider 
> ignoring upstream patches... What do you think would be the best?
> 
> Dropping kernel version check is a bit challenging as well due to multiple 
> references to this code. If you're sure it will be a cause for any troubles 
> perhaps we could modify the code of 'linux_version_code' function instead of 
> dropping it completely...

I exchanged a few emails with Ian, and the plan is to keep all this stuff
(but fixing the version check to allow 2-component version strings).  With
new kernel interface it does not really matter if we read larger or smaller
packet, so the patch in question -- 5.0.6-allow-for-kernel-packet-size-change.patch --
makes no difference anyway, the code will work with or without that patch.

For older kernels it makes no difference too, since the version check will
prevent new code from being used.

So the userspace change is just useless, but it isn't wrong.  It merely
adds bloat and confusion, but not make the code misbehave.  So we may
just let it be there, especially since upstream really wants it to be
there (Ian says it is for documentation purposes).

I never said the code is wrong, but I really wanted to check with Ian
before going further.  This issue took quite some discusion and time
already, so I decided to at least understand the final intentions.

> Unfortunately this is a bit beyond my competency so I hope you have some 
> ideas.

And there's no need to do that, really.

I'm checking the package now, it all appears to be quite good (as I
already mentioned initially).

I'm verifying now whenever the transition works correctly.  Did you test
this place?  Is it possible to downgrade back to current version (and
name) of the package?

Thank you!

/mjt



Reply to: