According to policy, IUSE must always be set in ebuilds. Repoman does not detect ebuilds that don't set IUSE. Tom
It can't really figure that out... Bash sets up IUSE, so it's treated as a bash variable... Which is almost always defined regardless if how to read it.
IUSE is not mentioned in policy
It's in: http://www.gentoo.org/doc/en/gentoo-howto.xml In this document: Contents of an ebuild File / 1. Variable Settings: IUSE This is set to what USE variables your package uses. If your package uses none, you must set it to IUSE="" . This would be a docs bug if IUSE is not actually required -- if so please reopen and reassign to docs. Regards, Tom
that is a howto ebuilds, not policy ;) and yes, i'm redoing the docs
IUSE is required -> reopening
Added a IUSE missing check in cvs
The repoman IUSE check is broken for 2.0.51_pre7; specifically, it checks to see if the variable is empty, rather then if it's defined. So, using net-www/dansguardian as an example, repoman scan will flag IUSE.missing for 2.7.6 and 2.7.1, even though IUSE _has_ been defined. If I recall correctly, aux_get used to throw a key exception when trying to access a missing key- would be useful now, although that behaviour seems to have changed.
I noticed that and I'm fixing it now..
*** Bug 49929 has been marked as a duplicate of this bug. ***
Created attachment 31241 [details, diff] 2.0.51-cache fix, and key/value flat cache format This patch adjusts 3 areas to enable the missingvars repoman check to work correctly- A) ebuild.sh gives no indication if a variable was set, or is just null. The ebuild.sh modifications now outputs VARNAME=value pairs for dbkey; this removes the requirement that the exported dbkey's variable order is the same as what portage thinks it is (ancillary benefit), but mainly is a way of detecting if a variable wasn't defined (if it's not defined, then ebuild.sh doesn't output that variables pair). B) moved the UNUSED_* auxdbkeys into a specific portage_db database- this frees up portage to reorder auxdbkeys internally (and not maintain UNUSED_0-8 slots), requiring portage_db_metacache to maintain the appropriate order/parsing. Changed the default textual cache file to portage_db_flat_hash , storing data in KEY=value pairs. Since portage_db_* just returns a dict for get_values, and lets aux_get fill in the blanks- this isn't a change in aux_get's behaviour, since it previously returned "" for unknown auxdbkey requests. C) Took advantage of the strict parameter of aux_get- if an aux_get request is made w/ strict enabled, it returns None for unknown auxdbkeys. If strict isn't set, then it returns "" for that requested variable.
Few additionals- the text hash cache format I added a .th extension to keep the original dbkeys-layout flat cache files from getting uses w/ the text hash files. It ought to be possible to create a portage_db_flat_automatic.database that detects if the cache is hash, or the older format- this would be useful for the current metacache. If we switch the metacache format to an autodetect flatfile database, we maintain backwards compatability with the current format, but enable support *now* for later on using a hash metacache format, which eliminates a lot of issues w/ backwards compatability and the ordering/addition of variables. This ^^^ is debatable, and likely quite flamable :) Worth noting the repoman fix will not detect missing vars if the cache file is the current text format, or if the cache entry was imported from the current text format (eg, emerge metadata). There isn't any way to detect if the variable was null, or undefined w/out rerunning ebuild.sh ebuild depend. Also worth noting that a fix could be created just by changing echo `echo $DEPEND` >> $depkey into echo `echo ${DEPEND-unset}` >> $depkey I didn't go that route, since it requires aux_get to identify the unset value, and treat it differently. That route seemed a bit more prone to errors then just going key/value route.
Created attachment 31803 [details, diff] portage-2.0.51_pre7-cache-adjustments.patch Updated the patch, since it had a bug in ebuild.sh related to IUSE assignment- dumb typo, IUSE="$IUSE E_IUSE" when it should've been IUSE="$IUSE $E_IUSE". Made a few tweaks in aux_get beyond what earlier comments mentioned- basically, aux_get pulls the keys from the cache (and/or regenerates those keys via ebuild.sh), and stores them in a local cache for the function call duration. It still updates the caches as needed, just uses the local dict rather then going to disk every time a value is accessed. Basically, pkg_dict['desired_value"] rather then self.auxdb[loc][cat][pkg]["desired_value"] Seems to speed things up a nicely- pretty much an aux_get call now is typically a single read (possible write if the cache is stale).
Created attachment 32659 [details, diff] .51_pre10 updated, w/ autodetect metacache class Fix- long standing issues w/ vardbapi.lock_held being left on when aux_get's doebuild depend call fails- easy way to test/verify this, intentionally leave a quote open in an ebuild, run emerge regen, and watch portage fail for *every* ebuild after the broken ebuild. I can't see any reason to leave the lock on since we were already unlock'ing the dbkey file, so this patch also unlocked the vardbapi instance when bailing from aux_get. Meanwhile, reworked the patch. threw out portage_db_flat_template, leaving portage_db_metacache and portage_db_flat_hash. portage_db_metacache is an autodetect class- since the extension for flat_hash is different then the old flat format (addition of .th), autodetect first checks for the new hash format, then the old format, importing in that order. The current auxdbkeys (minus UNUSED_0*) has been copied into portage_db_metadata- it's the modules responsibility to keep the order correct now. Also, added an addition to emerge metadata that checks for metadata/cache_keys; cache_keys defines the keys that are used w/in the cache (eg, provide, iuse, src_uri)- if the users portage.auxdbkeys defines keys that the metadata/cache_keys lacks, then no point in trying to transfer metadata. This actually is kind of needed since when the metacache is moved to flat_hash, there isn't a way to detect removal of keys- basically an older client could expect XYZ to be exported, but in the current metacache it's been removed. The emerge patch catches this condition, outputting an appropriate statement. Aside from that, adjusted portage_util.grabdict/writedict so you can specify the key/value seperator used, remove portage.py's versions of those functions, and have portage just importing the functions from portage_util.
*** Bug 54525 has been marked as a duplicate of this bug. ***
ferringb, I've just fixed the problem by another solution in CVS. I think your patch is better than mine. (ex. Your patch considers inherit but mine donen't) But I don't have a time to look at your patch for now because your patch is big and modifying some files. We would rewrite repoman for portage API and could use your patch at the time.
Closing in the meantime. The patch above A) killed off the IUSE issues, but also optimized the cache, and added a textual hash format (good for mirrors). I'll push for it later, as is the repoman fix is in.
