Ionuț Mircea Bîru wrote:
Due to a bug in pacman file conflict resolution, the upgrade to the package
formerly named `zope-interface` requires manual steps.
pacman -Rdd zope-interface
pacman -Su python2-zope-interface --asdeps
URL: http://www.archlinux.org/news/python2-zope-interface-update-requires-user-i…
Tom Gundersen wrote:
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.
net-tools will continue to be in the repositories, so scripts relying on it
should still work.
## `rc.conf`
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 it to gain
new features.
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 `netcfg`.
## `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`.
## `hostname`
This binary is now provided by `coreutils`, rather than by `net-tools`.
URL: http://www.archlinux.org/news/deprecation-of-net-tools/
Tom Gundersen wrote:
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 gain.
Due to an unrelated change in our udev package, we no longer load as many
modules as we used to by default, so some problematic modules (such as `pcspkr`
and `snd-seq-oss`) might no longer need to be blacklisted.
## 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 manually.
* 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 or disabling
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` instead. This is useful in an
emergency where a broken module makes it impossible to boot your system.
## Persistent blacklisting or disabling
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
URL: http://www.archlinux.org/news/changes-to-module-blacklisting/