the files in /etc/modprobe.d/
Marco d'Itri
/etc/modprobe.d/ will be processed only if they have a .conf suffix.
The latest module-init-tool release complains loudly for each one and
still processes them, but this will change.
Please update your packages at the time of your next upload and remember
that the files in this directory are opened and parsed every time
modprobe is run (and it is run very often at boot time!), so
try to look at the big picture and install a file there only if it is
really needed. Do not install a file if it only contains comments, if
it is only useful for some unusual environment or if it not needed for
recent kernels (nowadays most drivers have their own aliases built in,
check /lib/modules/$KVER/modules.alias).
The packages affected are:
etc/modprobe.d/aliases admin/module-init-tools
etc/modprobe.d/alsa-base sound/alsa-base
etc/modprobe.d/alsa-base-blacklist sound/alsa-base
etc/modprobe.d/blacklist admin/udev
etc/modprobe.d/blacklist-berry_charge utils/barry-util
etc/modprobe.d/blacklist-capiutils net/capiutils
etc/modprobe.d/display_class admin/udev
etc/modprobe.d/eeepc utils/eeepc-acpi-scripts
etc/modprobe.d/gpib science/libgpib-bin
etc/modprobe.d/hostap-utils net/hostap-utils
etc/modprobe.d/i2c utils/lm-sensors
etc/modprobe.d/kqemu misc/kqemu-common
etc/modprobe.d/libphidgets0 libs/libphidgets0
etc/modprobe.d/libpisock9 libs/libpisock9
etc/modprobe.d/libsane libs/libsane
etc/modprobe.d/madwifi contrib/net/madwifi-tools
etc/modprobe.d/mt-st admin/mt-st
etc/modprobe.d/mwave non-free/utils/mwavem
etc/modprobe.d/nbd-client admin/nbd-client
etc/modprobe.d/nvidia-kernel-nkc contrib/x11/nvidia-kernel-common
etc/modprobe.d/pnp-hotplug admin/udev
etc/modprobe.d/rng-tools utils/rng-tools
etc/modprobe.d/rt73 contrib/net/rt73-common
etc/modprobe.d/sl-modem-daemon.modutils non-free/misc/sl-modem-daemon
etc/modprobe.d/thinkpad_acpi.modprobe admin/acpi-support
etc/modprobe.d/toshset utils/toshset
etc/modprobe.d/toshutils utils/toshutils
etc/modprobe.d/vmxnet contrib/admin/open-vm-tools
--
ciao,
Marco
Steve Langasek
> The upstream maintainers decided that in the future the files in
> /etc/modprobe.d/ will be processed only if they have a .conf suffix.
What is the point of this change, except to force an annoying transition on
people?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
> On Tue, Mar 03, 2009 at 01:43:53AM +0100, Marco d'Itri wrote:
> > The upstream maintainers decided that in the future the files in
> > /etc/modprobe.d/ will be processed only if they have a .conf suffix.
> What is the point of this change, except to force an annoying transition on
> people?
Being sure to ignore backups, packaging systems files, etc.
It's not that I like this much, but I'd rather not carry forever a patch
to restore the old behaviour.
--
ciao,
Marco
Joey Hess
about dh_installmodules(1), which can handle
modprobe.d files in addition to kernel modules. Most packages
shipping files in modprobe.d seem to generate the files via
echo statements in debian/rules, rather than using it.
dh_installmodules will handle renaming of the modprobe.d
files that it installs, in its next release. Including
conffile renaming on upgrade. So using it instead of those
echo statements will probably save you some pain.
<winge>
Insert the typical winge here about dpkg conffile renaming code
being deployed via cut-n-paste from a wiki page instead of any
of our better technologies, such as a utility, with a man page,
in a single package.
</winge>
--
see shy jo, who wishes he had his own fan newsgroup
Steve Langasek
Is there a chance upstream would accept a patch to implement this as a
blacklist instead of a whitelist?
Steve Langasek
> <winge>
> Insert the typical winge here about dpkg conffile renaming code
> being deployed via cut-n-paste from a wiki page instead of any
> of our better technologies, such as a utility, with a man page,
> in a single package.
> </winge>
It would of course have to be in an Essential: yes package, since conffile
renaming has to be handled in the package preinst and we wouldn't want
conffile handling to involve lots of extra Pre-Depends. dpkg itself is the
most likely package to carry this - wishlist bug on dpkg warranted?
Stefano Zacchiroli
> It would of course have to be in an Essential: yes package, since conffile
> renaming has to be handled in the package preinst and we wouldn't want
> conffile handling to involve lots of extra Pre-Depends. dpkg itself is the
> most likely package to carry this - wishlist bug on dpkg warranted?
Instead of dpkg itself, I would prefer a new, tiny teeny package,
meant to become a small lib of shell script snippets on which
maintainer scripts can rely: a sort of debhelper for maintainer
scripts. Of course it should better be maintained by the dpkg team,
but I guess having a separate source package can ease maintenance.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Russ Allbery
> On Mon, Mar 02, 2009 at 08:01:42PM -0800, Steve Langasek wrote:
>> It would of course have to be in an Essential: yes package, since
>> conffile renaming has to be handled in the package preinst and we
>> wouldn't want conffile handling to involve lots of extra Pre-Depends.
>> dpkg itself is the most likely package to carry this - wishlist bug on
>> dpkg warranted?
> Instead of dpkg itself, I would prefer a new, tiny teeny package, meant
> to become a small lib of shell script snippets on which maintainer
> scripts can rely: a sort of debhelper for maintainer scripts. Of course
> it should better be maintained by the dpkg team, but I guess having a
> separate source package can ease maintenance.
I'm not sure anyone else thinks this is a good idea except me, but I still
think there's a lot of merit in writing a custom interpreter designed
specifically for Debian maintainer scripts, with built-in functionality to
handle the top 20-50 things that we have to do. I suspect that we could
replace 90-95% of our maintainer scripts with ones written in such a
stripped down mini-language, which would then be far easier to analyze,
fix, and check for consistency. We could still use shell or Perl for the
really difficult cases when full generality is needed.
The advantage of such an interpreter over a shell library is that, for
those maintainer scripts that could use it, they *can't* do anything weird
because the language has no way of expressing it. So there's no
temptation to hack around the shell library and turn a simple expression
into one that can't be automatically verified as correct. The interpreter
can also then be responsible for the difficult work of figuring out when
to call programs in all the various edge-case error-handling cases.
(The obvious disadvantage is that a bunch of maintainer scripts really do
need shell, and the ones that could use such an interpreter are already
rather simple.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Raphael Hertzog
> On Mon, Mar 02, 2009 at 10:02:11PM -0500, Joey Hess wrote:
> > <winge>
> > Insert the typical winge here about dpkg conffile renaming code
> > being deployed via cut-n-paste from a wiki page instead of any
> > of our better technologies, such as a utility, with a man page,
> > in a single package.
> > </winge>
>
> It would of course have to be in an Essential: yes package, since conffile
> renaming has to be handled in the package preinst and we wouldn't want
> conffile handling to involve lots of extra Pre-Depends. dpkg itself is the
> most likely package to carry this - wishlist bug on dpkg warranted?
It's already there:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514316
I would happily include such a file, though it probably needs some thought
on the API before we commit to support it for eternity. Feel free to help
and make a proposal/patch.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Ferdi Thommes
a lot of warnings like:
modprobe: WARNING: All config files need .conf: /etc/modprobe.d/aliases, it
will be ignored in a future release.
there is blocks of those lines, one for each file in /modprobe.d,
those blocks are repeated 6 times during boot.
regards
--
Ferdi Thommes
2.Vorsitzender
sidux e.V.
_________________
Marco d'Itri
> Is there a chance upstream would accept a patch to implement this as a
> blacklist instead of a whitelist?
This is how it used to work (and still does).
--
ciao,
Marco
Guillem Jover
> On Mon, 02 Mar 2009, Steve Langasek wrote:
> > On Mon, Mar 02, 2009 at 10:02:11PM -0500, Joey Hess wrote:
> > > <winge>
> > > Insert the typical winge here about dpkg conffile renaming code
> > > being deployed via cut-n-paste from a wiki page instead of any
> > > of our better technologies, such as a utility, with a man page,
> > > in a single package.
> > > </winge>
> >
> > It would of course have to be in an Essential: yes package, since conffile
> > renaming has to be handled in the package preinst and we wouldn't want
> > conffile handling to involve lots of extra Pre-Depends. dpkg itself is the
> > most likely package to carry this - wishlist bug on dpkg warranted?
>
> It's already there:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514316
>
> I would happily include such a file, though it probably needs some thought
> on the API before we commit to support it for eternity. Feel free to help
> and make a proposal/patch.
Joey Hess already sent a proposal for a dpkg-conffile last year[0],
based on the wiki shell snippets. The problem I see with that is that
it's not properly integrated with the dpkg internals. And I'd expect
the interface to change once it is actually a proper C binary. The
current copy-and-paste solution and the scripts even if suboptimal and
cumbersome, work, but are a hack, a fine one though.
Introducing either a shell library or a non-integrated dpkg-conffile
has a too high cost IMO. It will prompt maintainers to switch to it
(when the annoying part is the initial introduction of the support,
being there already on packages currently needing it), which they might
then need to do again once we get a proper solution, and will mean
having to carry a deprecated interface for a long time, or not be able
to change the existing one. I'd rather work during this release cycle
on improving the general conffile support.
regards,
guillem
[0] <http://lists.debian.org/debian-dpkg/2008/01/msg00143.html>
Roger Leigh
run-parts uses a set of simple regular expressions to ignore both backup
files and dpkg conffile leftovers. This is the relevent code from the
schroot run-parts class:
bool match = false;
static regex lanana_namespace("^[a-z0-9]+$");
static regex lsb_namespace("^_?([a-z0-9_.]+-)+[a-z0-9]+$");
static regex debian_cron_namespace("^[a-z0-9][a-z0-9-]*$");
static regex debian_dpkg_conffile_cruft("dpkg-(old|dist|new|tmp)$");
if ((regex_search(name, lanana_namespace) ||
regex_search(name, lsb_namespace) ||
regex_search(name, debian_cron_namespace)) &&
!regex_search(name, debian_dpkg_conffile_cruft))
match = true;
You could easily adapt these expressions and logic (if needed,
they are very general) for use by modprobe.
Regards,
Roger
Stefano Zacchiroli
> Introducing either a shell library or a non-integrated dpkg-conffile
> has a too high cost IMO. It will prompt maintainers to switch to it
> (when the annoying part is the initial introduction of the support,
> being there already on packages currently needing it), which they
> might then need to do again once we get a proper solution, and will
> mean having to carry a deprecated interface for a long time, or not
> be able to change the existing one. I'd rather work during this
> release cycle on improving the general conffile support.
Hi Guillem, thanks for the improvement proposal, I guess we are all
eager to beta test it :)
Nevertheless, I don't get your argument against the essential package
containing the shell snippet library. To me, it looks very much like
debhelper. We are used to release of it with new features adding the
proper versioned dependency to ensure we have the right debhelper.
Sure we have potentially to deal with pre-dependencies, is that the
problem you were thinking at? While in general pre-dependencies are
bad because they can induce loops, in this specific case they will
always be towards the package containing the shell library which, in a
sense, will be a leaf of the pre-dependency graph.
In principle, that package can be dpkg itself (as it was suggested by
Joey). Note how we regularly write down in release notes to first
upgrade dpkg and then go ahead with the rest of the upgrade. That
would trivially solve the usual pre-dependency potential issues.
We do have evidence that there exist several de facto patterns in
maintainer scripts which are just copy & pasted around. That is
bad(TM), having a place where to factorize them IMO is a must.
/me just trying to understand whether I'm missing something of the
global picture
Raphael Hertzog
> On Tue, 2009-03-03 at 09:02:18 +0100, Raphael Hertzog wrote:
> > It's already there:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514316
> >
> > I would happily include such a file, though it probably needs some thought
> > on the API before we commit to support it for eternity. Feel free to help
> > and make a proposal/patch.
>
> Joey Hess already sent a proposal for a dpkg-conffile last year[0],
> based on the wiki shell snippets. The problem I see with that is that
> it's not properly integrated with the dpkg internals. And I'd expect
> the interface to change once it is actually a proper C binary. The
> current copy-and-paste solution and the scripts even if suboptimal and
> cumbersome, work, but are a hack, a fine one though.
I agree with that but I don't see how it also applies to a shell library.
Once you have a proper C binary, the shell library can simply be modified
to wrap around the C binary.
We just have to make sure that the input parameters of the shell functions
contain everything we might need in the future. And also that the set of
places where we require people to call those functions allow us to
implement most ideas/request concerning conffile handling that we already
know.
And even if conffile renaming is integrated into dpkg itself so that
nothing is needed in maintainer scripts, it's easy to change those
functions back to be no-ops emitting some warnings (if we can't transition
progressively).
> Introducing either a shell library or a non-integrated dpkg-conffile
> has a too high cost IMO. It will prompt maintainers to switch to it
> (when the annoying part is the initial introduction of the support,
> being there already on packages currently needing it), which they might
> then need to do again once we get a proper solution, and will mean
> having to carry a deprecated interface for a long time, or not be able
> to change the existing one. I'd rather work during this release cycle
> on improving the general conffile support.
I don't think introducing a shell library would forbid you to improve
the general conffile support.
That said, we can certainly wait a bit more, until Squeeze plans wrt conffile
handling have been elaborated.
Cheers,
--
Raphaël Hertzog
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
Marco d'Itri
> You could easily adapt these expressions and logic (if needed,
> they are very general) for use by modprobe.
I did this in 2004. Upstream was not interested.
--
ciao,
Marco
Steve Langasek
> On Tue, Mar 03, 2009 at 04:17:00PM +0200, Guillem Jover wrote:
> > Introducing either a shell library or a non-integrated dpkg-conffile
> > has a too high cost IMO. It will prompt maintainers to switch to it
> > (when the annoying part is the initial introduction of the support,
> > being there already on packages currently needing it), which they
> > might then need to do again once we get a proper solution, and will
> > mean having to carry a deprecated interface for a long time, or not
> > be able to change the existing one. I'd rather work during this
> > release cycle on improving the general conffile support.
> Hi Guillem, thanks for the improvement proposal, I guess we are all
> eager to beta test it :)
> Nevertheless, I don't get your argument against the essential package
> containing the shell snippet library. To me, it looks very much like
> debhelper. We are used to release of it with new features adding the
> proper versioned dependency to ensure we have the right debhelper.
If the facility is later implemented as a C executable (or whatever)
instead of a shell lib, the shell lib would still have to be shipped in dpkg
so that maintainer scripts don't fail ungracefully when trying to source it.
That makes it hard to ever get rid of that interface once deployed.
> In principle, that package can be dpkg itself (as it was suggested by
> Joey). Note how we regularly write down in release notes to first
> upgrade dpkg and then go ahead with the rest of the upgrade. That
> would trivially solve the usual pre-dependency potential issues.
No, the way to get dpkg upgraded first is by declaring the Pre-Dependency on
dpkg. Then, if there *is* a pre-dependency loop, it's detectable and should
be resolved...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Stefano Zacchiroli
> If the facility is later implemented as a C executable (or whatever)
> instead of a shell lib, the shell lib would still have to be shipped in dpkg
> so that maintainer scripts don't fail ungracefully when trying to source it.
> That makes it hard to ever get rid of that interface once deployed.
Fair enough, this is a good argument against the shell lib
approach. It works pretty well with the conffile case, especially now
that Guillem announced it will work on it directly within dpkg.
Still, shell lib vs C implementation shows the unavoidable trade off
between being easier to deploy (shell lib) and becoming part of dpkg
itself (C implementation). *If* the goal is building a place where to
start factorizing tons of maintainer script snippets that we are
accumulating then shell lib looks, at least to me, more appropriate
and more readily available.
> > In principle, that package can be dpkg itself (as it was suggested by
> > Joey). Note how we regularly write down in release notes to first
> > upgrade dpkg and then go ahead with the rest of the upgrade. That
> > would trivially solve the usual pre-dependency potential issues.
>
> No, the way to get dpkg upgraded first is by declaring the
> Pre-Dependency on dpkg. Then, if there *is* a pre-dependency loop,
> it's detectable and should be resolved...
Don't blame me for the release notes :-), I'm culpable of not having
contributed a single line to them.
But I do agree with you, and that's actually even better. It will just
mean that if packages are fine with the current stable version of the
maintainer script helper package, fine, otherwise they will just add a
Pre-Dependency as usual. As long as the helper package maintainers are
sane-minded, we will never have pre-dep loops.
Frans Pop
> The upstream maintainers decided that in the future the files in
> /etc/modprobe.d/ will be processed only if they have a .conf suffix.
> The latest module-init-tool release complains loudly for each one and
> still processes them, but this will change.
Any idea when the warning will be dropped?
IMO the warning, and support for files without .conf, should be kept
active in Debian at least until after the release of Squeeze as users may
have added local modprobe.d files without a .conf extention. In that case
the first time they would see any warnings would be during a lenny to
squeeze upgrade.
Cheers,
FJP
Marco d'Itri
> > The latest module-init-tool release complains loudly for each one and
> > still processes them, but this will change.
> Any idea when the warning will be dropped?
Upstream says it's not decided yet. Probably not soon, but probably not
for two years either.
--
ciao,
Marco
Julien BLACHE
Hi,
> etc/modprobe.d/libsane libs/libsane
Removed in 1.0.19-26.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jbl...@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Joey Hess
dpkg-conffile(8) utility.
Note that the code on the wiki has changed slightly to handle a couple
of cases since I wrote dpkg-conffile last year. The wiki version puts a
space after $CONFFILE here to work around a bug:
old_md5sum="`dpkg-query -W -f='${Conffiles}' $PKGNAME | sed -n -e \"\\\\' $CONFFILE '{s/ obsolete$//;s/.* //p}\"`"
I don't understand why some are talking about shell libraries. As the
author of probably the most commonly used shell library in Debian
(confmodule.sh), I can tell you that they are a *very* bad idea
for forward maintainability. They're also a PITA to access from
maintainer scripts that are not written in shell.
dpkg-conffile(8) has no more business being a shell library than do
dpkg-divert(8) or update-alternatives(8).
I really hope that this doesn't degenerate into bikeshedding, and that the
current slow-motion cut-n-paste train wreck is averted. The best way
to avoid both pitfalls is to put the current best practice code for managing
conffiles into a single place, immediatly. If dpkg's handling of conffile
delete/rename is significantly improved afterwards, you will then have
one place to change or deprecate.
--
see shy jo
Raphael Geissert
> I'd rather work during this release cycle
> on improving the general conffile support.
>
What about modifying the format of conffiles to allow:
<conffile>[ <old conffile>]
Which would let dpkg know that it should look for <old conffile> and rename
it to <conffile> (usual change-detection should apply); if it doesn't exist
then just install the new file.
A debhelper script could later ease the editing of conffiles for that
pourpose.
Cheers,
Raphael Geissert