This is the analogue of bug 467276 for ufed: If /etc/portage/make.conf is a folder, ufed becomes confused, e.g.: Use of uninitialized value $_ in pattern match (m//) at /usr/share/ufed/Portage.pm line 797. I was not curageous enough to attempt to save changes in this case.
Where can I find information about make.conf being a folder? What is the purpose of this? man 5 make.conf says: NAME make.conf - custom settings for Portage SYNOPSIS /etc/make.conf and /etc/portage/make.conf DESCRIPTION This file contains various variables that are used by Portage. With the description saying "file". There is no information about make.conf being a directory. I have checked emerge(1) and portage(5), too. make.conf is referenced as being a file only everywhere. But those man pages are huge, I might have overlooked the relevant section. (And Google didn't help either.) As soon as I understand what the purpose is, and what I am supposed to find in such a directory, I can fix ufed. (My Portage version is 2.2.0_alpha173, the quoted bug talks about 2.1.11.62 - Is this the catch?)
(In reply to comment #1) > Where can I find information about make.conf being a folder? I don't know, I just tried when the bug was reported for eix: It appears that /etc/portage/make.conf being a directory is handled analogously to the case of /etc/portage/package.* being a directory: Recursively all files in this directory are used, the order being alphabetically (_not_ depth first) (I tried only separating at "sane" places, i.e. not in the middle of a line or string). As for /etc/portage/package.*, directories with the name CVS RCS SCCS are ignored, and the same holds for files/dirs starting with . or ending with ~
I have added the functionality to the git repository. The changes can be tested using app-portage/ufed-9999. At the beginning of Portage.pm there is a readonly variable "$DEBUG". Set this to 1 and ufed will tell you which files get read and which get skipped. A testing on my laptop reads: --- Skipping file /etc/portage/make.conf/compilersettings.old Skipping directory /etc/portage/make.conf/general/CVS Skipping file /etc/portage/make.conf/other.bak Skipping file /etc/portage/make.conf/portagesettings.tmp Skipping directory /etc/portage/make.conf/RCS Skipping directory /etc/portage/make.conf/SCCS Skipping file /etc/portage/make.conf/USE_flags~ Skipping file /etc/portage/make.conf/USE_flags~.old Reading /etc/portage/make.conf/compilersettings Reading /etc/portage/make.conf/CVS Reading /etc/portage/make.conf/general/nodoc -> USE flags found Reading /etc/portage/make.conf/other Reading /etc/portage/make.conf/portagesettings Reading /etc/portage/make.conf/USE_flags -> USE flags found Using /etc/portage/make.conf/USE_flags as USE flags file /etc/portage/make.conf/USE_flags will be used to store changes USE flags written to /etc/portage/make.conf/USE_flags --- Sorry for the long wait.
Sorry, I was busy at a conference. Thanks a lot for your good work. It works nicely, with one exception: ufed now has different rules to ignore files in the folder (portage only ignores .*, *~, CVS, RCS, SCCS). This is a problem, because portage does not ignore *.old which is used as a backup extension. In particular, portage gets different information from the *.old file. I suggest to rename the backup files to *~ instead of *.old (or maybe even omit backups at all, at least optionally?) and to _not_ ignore *.old files.
(In reply to Martin Väth from comment #4) > This is a problem, because portage does not ignore *.old which is used as a > backup extension. In particular, portage gets different information from the > *.old file. > > I suggest to rename the backup files to *~ instead of *.old (or maybe even > omit backups at all, at least optionally?) and to _not_ ignore *.old files. That's mean. Portage ignores any file that is named "make.conf?*". (Just checked with strace) But now with the directory style the original file will be read when named "*.old"... I'll do some more tests, then. Changing to a ~ backup looks best to me, but ufed should ignore any make.conf?* file, too.
Changed as suggested. The changes can be tested using the live ebuild. Sorry everybody that this took so long. Unfortunately private tragedies do not tend to announce their arrival beforehand. However, I am back on working on my todo list.
ufed doesn't work with /etc/portage/make.profile as folder aswell. portage supports it for some time.
(In reply to Oleg from comment #7) > ufed doesn't work with /etc/portage/make.profile as folder aswell. portage > supports it for some time. make.profile? Oh, man come on, what is that supposed to be good for anyway?
(In reply to Sven Eden from comment #8) > (In reply to Oleg from comment #7) > > ufed doesn't work with /etc/portage/make.profile as folder aswell. portage > > supports it for some time. > > make.profile? Oh, man come on, what is that supposed to be good for anyway? Okay, current live version (meant to become version 0.91) supports make.profile symlink and directory. ufed only errors out if it is a file instead.
This bug is fixed with the new version 0.91 in the tree.
