[arch-general] [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

[Marek Otahal]

Hello Tom, 
thanks for the pre-announcement, looks good. I have just a question..
Since net-tools are going to be abandoned (I was wondering how i "misuninstalled" the package), what do i use as an alternative to ifconfig? I use wicd or manually bring LAN up, and it occurred to me network interfaces failed due to missing ifconfig command. What is the new one? Thanks
On Tuesday 07 of June 2011 23:21:11 Tom Gundersen wrote:
> 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.
> 
> `hostname`
> ----------
> 
> 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`.
> 
> `network`
> ------------------------------
> 
> 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
> `netcfg`.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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
> gain.
> 
> 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
> ---------------------------
> 
> 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.
> 
> 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
> 

-- 

Marek Otahal :o)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20110607/286007cb/attachment.asc>