On 01/27/2017 01:01 PM, Dirkjan Ochtman wrote: > On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp <[email protected]> wrote: >> Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilbert: >>> I recently ran into a REQUIRED_USE constraint that required I select >>> between berkdb and gdbm for an email client. >> There shouldn't be a REQUIRED_USE constraint that forces you to select >> one or the other. The maintainer should be giving the choice of both, >> but if only one can be chosen, the maintainer should make the choice >> for you by preferring one of them. Likely gdbm, given berkdb licensing >> saga. > I'm not sure this makes sense to me. If the package will actually > select one implementation out of a set, it makes sense to me that the > maintainer for that package makes that choice explicit towards the > user. In that case, setting REQUIRED_USE accordingly seems exactly > right. The maintainer should set a good default, but if the user's USE > settings are inconclusive in getting to the choice of implementation, > it's better to whine explicitly than try to guess implicitly what the > user wanted.
I tend to agree with this sentiment, explicit over implicit behavior ensures better debugging ability and security considerations. > > On Fri, Jan 27, 2017 at 9:32 AM, Fabian Groffen <[email protected]> wrote: >> Replying here because I think said email client is the one I recently >> added REQUIRED_USE constraints for. >> >> Reason I added it is because it greatly simplified the ebuild: it's not >> just bdb and gdbm, but also tokyocabinet, qdbm and lmdb, with as result >> a lot of if-else-casing which implemented the implicit defaults before. >> I didn't realise changing this to REQUIRED_USE resulted in a conflict on >> default profiles, because I (obviously) have a package.use entry for the >> package. > I don't see Mike saying you got it wrong here. Reading your email, I > think you did the right thing. Yup -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
signature.asc
Description: OpenPGP digital signature
