On 11/28/2010 10:15 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2010-11-19 16:51:03 Zac Medico napisał(a):
>> On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
>>> use.unsatisfiable and package.use.unsatisfiable files would cause that `repoman` would treat
>>> given USE flags in the same way as masked USE flags. These files wouldn't affect behavior of
>>> `emerge`:
>>>  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
>>>    and if optional dependencies controlled by this USE flag are already installed or satisfiable,
>>>    then `emerge` will allow to install given package.
>>>  - If user has enabled given USE flag specified in use.unsatisfiable or package.use.unsatisfiable
>>>    and if optional dependencies controlled by this USE flag cannot be satisfied (with current
>>>    settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then `emerge` will print
>>>    informative error message telling e.g. about a dependency masked by ~${ARCH} keyword.
>>
>> Can't we print a "masked by ~${ARCH} keyword" message as you suggest,
>> even without the use.unsatisfiable data? If so, then isn't
>> use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
>> use.mask, so I don't see any value added.
> 
> repoman sometimes needs to allow stable packages to have optional dependencies on unstable
> packages (usually until these packages are stabilized). My patch implements this functionality
> for repoman.

It seems like you're trying to bypass an important function of repoman
though. The idea is that repoman is supposed to protect users from
experiencing unsatisfiable dependencies of this sort, and use.mask
accomplishes that. With your use.unsatisfiable patch, it makes repoman
quiet, while leaving users unprotected from unsatisfied dependencies.
-- 
Thanks,
Zac