[arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3

Tom Gundersen teg at jklm.no
Tue Jun 7 17:21:11 EDT 2011

Since these update introduces some important changes I'd like to make
two announcements before it is moved to core (which should be as soon
as we have the missing i686 signoff).

Drafts below, comments welcome.

Announcement one:

Deprecation of net-tools

This April marked the ten year anniversary of the last net-tools
release. We decided to look at this as an opportunity to deprecate
net-tools and provide alternative, and better maintained, solutions
for net-tools functionality. This has a few consequences, but most
people should not notice.


This binary is now provided by `coreutils`, rather than by `net-tools`.

`domainname` (a.k.a. `nisdomainname`, a.k.a `ypdomainname`)

These binaries are now provided by `yp-tools`, rather than by
`net-tools`. Furthermore, the domain name is no longer set by
initscripts, rather it is dealt with entirely by the ypbind rc script.

Before this change the domain name was handled inconsistently,
sometimes being read from `/etc/conf.d/nisdomainname`, and sometimes
from `/etc/defaultdomain`. From now on, the domain name is only ever
read from `/etc/conf.d/nisdomainname`.


A new syntax is introduced in `rc.conf` for configuring a simple
network setup using `iproute2` rather than `net-tools`. The old
functionality is still preserved for those preferring to stay with
that, but do not expect updates for this.

The new syntax is very simplistic and only supports one wired network
device (configured statically or by dhcp) and we do not expect to add
more features in the future. We want to encourage the use of more
advanced network solutions, such as `networkmanager` or our own

Announcement two:

Changes to module blacklisting

Since the dawn of time we have shipped our homegrown system for
blacklisting kernel modules (in various incarnations). This has served
us well, but we (or rather our various upstreams) have now reached a
point where it is no longer necessary.

We have therefore decided to remove all our module blacklisting logic,
and rely entirely on the blacklisting provided by `modprobe`. This
means a change in syntax, and a minor change in functionality. We hope
that the short-term inconvenience will be justified by the long-term

The different notions of blacklisting

The notion of module blacklisting that we have used is (sadly)
slightly different from what is used by modprobe.

* our blacklisting: a blacklisted module, or any module that depends
on it, will never be loaded automatically by udev, but may be loaded
* modprobe's blacklisting: a blacklisted module will not be loaded
automatically, but may be loaded if another non-blacklisted module
depends on it, or if it is loaded manually.
* disabling a module: one can get similar behavior to what we used to
provide by forcing a module to always fail loading, it will not be
possible to load it manually.

Boot time blacklisting

Modules can be blacklisted at boot time by appending
`modprobe.blacklist=mod1,mod2,mod3` to the kernel command line (in
grub, lilo or syslinux). Alternatively, the modules can be disabled
altogether by appending `mod1.disable=1 mod2.disable=1 mod3.disable=1`

Persistent blacklisting

Rather than blacklisting modules in `rc.conf`, use modprobe's native
configuration files. These can be found in /etc/modprobe.d/, and are
documented in `man modprobe.d`.

The replacement of `rc.d`'s `MODULES=(!mod1 !mod2 !mod3)` is to add a
`.conf` file to `/etc/modprobe.d/` with the contents:

    blacklist mod1
    blacklist mod2
    blacklist mod3

Alternatively, to ensure that the modules are never inserted, even if
they are needed by other modules you load:

    install mod1 /bin/false
    install mod2 /bin/false
    install mod3 /bin/false

More information about the arch-dev-public mailing list