With sys-apps/module-init-tools-3.9, many modprobe invocations by init scripts will result in messages like this: WARNING: All config files need .conf: /etc/modprobe.d/foo, it will be ignored in a future release. So I would expect Gentoo to replace all files foo in /etc/modprobe.d with foo.conf in a way that allows for wasy upgrading. A fully updated system should imho not issue any warnings of this kind. Right now, there are still some packages that haven't switched to .conf files. Looking at the portage tree, these seem to be: * app-emulation/kqemu * net-dialup/misdn * net-dialup/mwavem * net-misc/ifenslave * net-wireless/ipw3945d * net-wireless/irda-utils * sys-apps/x86info But even those that have been switched over will simply create the new foo.conf file, not migrate any existing foo file. This can lead to config changes not noticed by etc-update, as well as conflicting options for some modules. The only exception to this seems to be media-video/em8300-modules which actually does migrate config files in pkg_preinst. I would wish for every package to use the new foo.conf file names, and to use some migration technique similar to em8300-modules. Given the number of packages affected, maybe an eclass function would be prudent.
Possibly related to bug #215626. A proper migration function should take that migration into account as well, as the one from em8300-modules does.
Let's make this a tracker bug for all packages who need adjustment of their files in /etc/modprobe.d/
This happens to the alsa package too, so add media-sound/alsa-utils to the list. It took me some time before I found this out. The problem exists because /usr/sbin/alsaconf creates/edits a file /etc/modules.d/alsa, I think. Adding the relevant lines from this file to /etc/modprobe.d/alsa.conf and subsequently deleting it solves the problem.
(In reply to comment #3) > add media-sound/alsa-utils to the list. The list is about "packages that haven't switched to .conf files", which doesn't apply to alsa-utils. Instead it belongs to the even larger list of ebuilds that don't migrate old config files properly. A command like "fgrep modprobe.d /usr/portage/*-*/*/*.ebuild" will give you the hopefully complete list, including em8300-modules as a false positive. I'd like to see one bug report for every such ebuild eventually, but if there is going to be some eclass function to deal with this, it should get written first, so that maintainers taking care of the bugs can immediately build on the eclass. Is this going to happen?
Two more packages: slmodem and madwifi-ng
this is a tracker bug, not a place for you to note packages. please file a bug for each package.
What shall we do with old files? As noted in bug 302413 and bug 302415 after reemerging new files exist, but old one are still in place too. Should we add ewarn to ask people remove them manually, remove them or... what?
Imho the proper approach would be migrating files in pkg_preinst, as I mentioned in comment #0 giving media-video/em8300-modules as an example. I would have liked to see an eclass function for it, as I wrote in comment #4. Now that plenty of packages have been moved over without such an eclass function, writing such a function would become much messier, as it would have to properly deal with the now common case of both the old and the new file existing. Given the effort it might take to get that right, maybe an ewarn and manual interaction is the proper solution, but I believe you really missed an opportunity there of giving users a clean smooth migration. Unless those packages have already been stabilized (haven't checked), there is still a chance. Write an eclass function now, migrate old files if the new ones don't exist, or are equal to the new files about to be merged. Only if both old and new files exist, and the new files differ from those about to be installed, then ewarn about the issue and ask users to manually merge them and delete the old one.
we could add a general routine to module-init-tools when it upgrades to compare files in the dir and auto delete non-.conf files when they're duplicated, or rename them to magic ._cfg_xxxx style so that they show up in etc-update automatically. we could also add a pkg_setup() check that scans the modprobe.d dir and refuses to upgrade if a config file was found that didnt have a .conf version at all.
Created attachment 217766 [details, diff] module-init-tools-3.11.1.ebuild.patch This patch does the first part: in case there are both file and file.conf it'll rename file into ._cfg_????_file.conf. I think this is rather safe and should cover cases in bugs I've mentioned. For other cases I'm sure manual intervention will be required, but it's better to postpone this until support for files without .conf will be dropped. Please, review and if this code is ok, commit.
(In reply to comment #10) > Please, review and if this code is ok, commit. This might confuse users, as their etc merging tools will compare files in the reverse order of how they are usually handled: 1. old version of package foo merges "foo" 2. user maybe edits "foo" 3. newer version of package merges "foo.conf" 4. etc-update doesn't notice the duplicate config files at all 5. updating module-init-tools moves "foo" to "._cfg_0000_foo.conf" 6. now the old ex-"foo" is considered a new replacement for the new "foo.conf" Users pressing well-known keys for "simply keep my stuff" or "simply use new stuff" will get unexpected results in this scenario. Furthermore, there are some issues with the patch. First and foremost, it checks the existence of ${cfg} but moves to ${cfg}.conf. I guess you'd want to use ${cfg}.conf in all cases, or include the .conf in ${cfg}. I'm not sure if it would be worth the effort to check whether there are any filles called ._cfg_*_foo not ending in .conf. If so, the users might miss some reconfigurations, but I doubt that should be an issue. I'm more worried about stale config files, and how config merging tools would deal with them. It seems to me slightly inconsistent to use ${f%/*} for the dir part but {f/*\/} for the basename part; I'd personally prefer ${#*/} for the latter. Minor cosmetic issue, though. I also believe that occurrences of ${f} and derived values should be quoted in the mv invocation. Both ROOT and the file basename might contain spaces.
agreed, you want to rename the newer ".conf" version to the _cfg_xxx and rename the older non-.conf version with a .conf suffix your patch also has a little odd style ... - to chop the tail, use: ${f%.conf} - might want to create a local "d" variable to hold the dir to clarify things - the final `mv` needs quoting around variables - i'm guessing "f" is already declared local earlier on in the func
Created attachment 217797 [details, diff] module-init-tools-3.11.1.ebuild.patch Many thanks Martin and Mike. This is an updated version of patch. I hope this version is clearer (and bug free). Please, review another time.
(In reply to comment #13) > Created an attachment (id=217797) [details] > module-init-tools-3.11.1.ebuild.patch > > Many thanks Martin and Mike. This is an updated version of patch. I hope this > version is clearer (and bug free). Please, review another time. Looks much better. I guess I'd use "cd ..." and "cd - > /dev/null" instead of "pushd" and "popd", but that's mostly a matter of taste. I also believe that the first cd should die on error. Or maybe not die, but eerror and return. Yes, ${ROOT}/etc/modprobe.d/ should exist, but if anything strange happens and it doesn't, we don't want to garble the current directory (which according to PMS is undefined).
Created attachment 217824 [details, diff] module-init-tools-3.11.1.ebuild.patch Let's just do nothing in case such dir does not exist.
ive implemented support with: http://sources.gentoo.org/sys-apps/module-init-tools/module-init-tools-3.11.1.ebuild?r1=1.2&r2=1.3
(In reply to comment #16) > ive implemented support [...] I'd suggest elog instead of einfo when asking users to etc-update, but besides that it looks fine to me. Yes, I should have spotted the einfo earlier, sorry.
http://sources.gentoo.org/sys-apps/module-init-tools/module-init-tools-3.11.1.ebuild?r1=1.3&r2=1.4
The patches work as intended (http://bugs.gentoo.org/show_bug.cgi?id=302413#c6). It is a pity that there is no way to just rename user's current foo file to foo.conf and install the default file under ._cfg*foo.conf instead.
no more open issues i believe
