Bug#647287: swapon no longer available on kfreebsd-amd64

[Michael Tokarev <mjt@tls.msk.ru>]

tags 647287 + confirmed pending
thanks

On 01.11.2011 19:49, Robert Millan wrote:
> Package: busybox-udeb
> Version: 1:1.19.3-1
> Severity: normal
> Tags: d-i
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
> 
> Hi Michael,
> 
> Thanks for fixing the latest FTBFS problems on GNU/kFreeBSD.  Unfortunately
> with version 1:1.19.3-1 there's a new regression: swapon is no longer available
> in busybox-udeb.  This has the unfortunate consequence of breaking swap support
> in D-I.
> 
> This is a bit confusing because debian/config/pkg/udeb still lists
> CONFIG_SWAPONOFF=y and this file appears to be kernel-independant.

Yes it's indeed messy.

The story is: in bb 1.19, all stuff that was dependent on
PLATFORM_LINUX become enabled by default, and now select
PLATFORM_LINUX instead.  So enabling any applet or other
config option which is believed to be linux-specific somehow
enables that option too.  Nothing interesting actually
changes when this option is enabled.  But the side effect
is that now, all really linux-specific config options are
enabled even if PLATFORM_LINUX has been disabled in the
configuration.

So I had two choices:

 1.  For every applet/option that selects PLATFORM_LINUX,
   check if it builds on non-linux platforms, and disable
   it explicitly if it is indeed does not compile on non-
   linux.

  2.  Disable all applets/options that selects PLATFORM_LINUX.

Optioin #1 is non-productive - I can't realistically check
every option on at least 2 more platforms (hurd and kfreebsd),
and next update will have the same issue with all new options
too.  So I went the #2 route.

So now, there's a hackish script in debian/rules that finds
and disables all options which select PLATFORM_LINUX.  This
includes SWAPONOFF, which is marked as such too.  So all
further assignments to this config option, including the
one in the debian/config/os/kfreebsd, are ignored.  Sigh.

For this very case, it looks like changing order of the
config options should do the trick - ie. place explicit
overrides first, implicit mass-disables next, and original
config last.  And that's how I'll fix this, too.  But this
is getting really really messy... :(

And I've no idea why ldv changed this very place.

The fix is to change order of operations in debian/rules,
the place should be easy to find.

Thanks,

/mjt