Every now and then a discussion pops into the forums or IRC about that flag, people being confused of what it is about. It sounds like it'll make linux-firmware redistributable while in reality it includes additional files. As a result people are disabling it and wondering why their firmware is not installed. I think the name of this use flag should be reconsidered. Something like non-free or something else that would bring the user's attention to what the flag really is about. Reproducible: Always This is just one example but I remember numerous others: https://forums.gentoo.org/viewtopic-t-1172281.html I myself learned the real meaning of this flag from one of those occasions and I doubt I myself would have understood its description correctly if I didn't know in advance.
Perhaps worth noting that the flag defaults on (so someone would have to go out of their way to disable it; perhaps a good opportunity for them to read the description for it) and the flag's description (available through metadata.xml or tools like equery) is: redistributable: Install also non-free (but redistributable) firmware files
(In reply to Greg Kubaryk from comment #1) > perhaps a good opportunity for them to read > the description for it) and the flag's description (available through > metadata.xml or tools like equery) is: > redistributable: Install also non-free (but redistributable) firmware files It's not very nice to put the blame on the user. As I already mentioned, the name is misleading and does not suggest there's something special to it and the user does not now what the reason for their problem is while in fact it's thinking like yours that created it first place.
The flag's name originates from a discussion in #gentoo-council on 2019-05-14, see bug 318841 comment #20. In that discussion, I had originally suggested the name "non-free", but it wasn't accepted because it is somewhat ambiguous. We then considered "binary-redistributable" (too long), "redist" (possibly ambiguous) and "redistributable", and settled on the last one. Another argument was that the flag names "redistributable" and "unknown-license" correspond to the tags used in the upstream WHENCE file, namely "Licence: Redistributable" and "Licence: Unknown" (see e.g. the first two entries in WHENCE of linux-firmware-20241210).
I also think "non-free" as a flag name would be more _obvious_. By reading the flag description its effect comes clear. Then there's the problem with the flag name change: There needs to me some sort of transition phase where both flags do the same, but the older triggers elog warning about the deprecation. This change would also need to be done with other packages which has USE="redistributable" available. My suggestion would be to leave the flag as-is, but modify the ebuild to emit elog notify if the flag is disabled that the non-free files will not be installed (or were not installed). Something like "skipping installation on non-free firmware files as 'redistributable' USE -flag is disabled." Also, I had a thought that _maybe_ the inclusion on these non-free files could be controlled by ACCEPT_LICENSE. I don't know if method is allowed. Just a thought.
(In reply to Ilja ”Zucca” Sara from comment #4) > My suggestion would be to leave the flag as-is, but modify the ebuild to > emit elog notify if the flag is disabled that the non-free files will not be > installed (or were not installed). Something like "skipping installation on > non-free firmware files as 'redistributable' USE -flag is disabled." The ebuild does this already (not as elog but as einfo): if use !redistributable; then einfo "Removing non-redistributable files ..." > Also, I had a thought that _maybe_ the inclusion on these non-free files > could be controlled by ACCEPT_LICENSE. I don't know if method is allowed. There is no mechanism for that. ACCEPT_LICENSE can only control acceptance of the package as a whole, not of individual files in it.
(In reply to Ulrich Müller from comment #5) > The ebuild does this already (not as elog but as einfo): > > if use !redistributable; then > einfo "Removing non-redistributable files ..." IMO, that should be changed to elog for more visibility. > > > Also, I had a thought that _maybe_ the inclusion on these non-free files > > could be controlled by ACCEPT_LICENSE. I don't know if method is allowed. > > There is no mechanism for that. ACCEPT_LICENSE can only control acceptance > of the package as a whole, not of individual files in it. Thanks for confirming.
(In reply to Ulrich Müller from comment #3) > In that discussion, I had originally suggested the name "non-free", but it > wasn't accepted because it is somewhat ambiguous. Exactly the ambiguity is what would make one seek clarity and draw attention to the description. In #318841 you said: (In reply to Ulrich Müller from comment #20) > 1. Two USE flags "redistributable" and "unknown-license" will be added to > sys-kernel/linux-firmware, controlling installation of non-free files. > > 2. The ebuild will have a default of IUSE="+redistributable > unknown-license", in order to provide a useful default for the vast majority > of users. For example, most wireless cards will require non-free/non-libre > firmware. > > 3.a. USE="-redistributable" will only install files with a license in the > @FREE set. (The USE="-redistributable unknown-license" setting wasn't seen > as useful, so the unknown-license flag can be ignored if redistributable is > not set.) > 3.b. USE="redistributable -unknown-license" (the default) will additionally > install files with a license in @BINARY-REDISTRIBUTABLE. > 3.c. USE="redistributable unknown-license" will install all files. > > 4. A restriction "unknown-license? ( bindist )" will be added to the ebuild. > > 5. The "unknown-license" flag will be package.use.masked (or use.masked) in > profiles, to prevent accidental installation of these components. > > 6. Mirror restriction of the distfile was not seen as necessary, for the > time being. What do you think of inverting that logic - adding a flag, say "free", disabled by default, which when enabled, strips out all blobs which are known not to be free or unclear and if it's disabled. Separate those further with non-free and unknown-licence. How does something like that sound? Best Regards, Georgi
(In reply to Georgi from comment #7) > What do you think of inverting that logic - adding a flag, say "free", > disabled by default, which when enabled, strips out all blobs If I'm not mistaken, the goal for USE flag logic is that when enabled it would _add_ something to the build.
(In reply to Georgi from comment #7) > What do you think of inverting that logic - adding a flag, say "free", > disabled by default, which when enabled, strips out all blobs which are > known not to be free or unclear and if it's disabled. Separate those further > with non-free and unknown-licence. I'd rather not use negative logic for one of the flags because I think it would be confusing. I'm aware that https://devmanual.gentoo.org/general-concepts/use-flags/index.html#noblah-use-flags doesn't exactly apply here. Still, users have become familiar with the concept that the vast majority of flags use positive logic. Anyway, I've explained how the current name came about, and it's for the package maintainers to decide on the name of their USE flags. So at least for now, I'm out of here.
@Georgi, Ilja: would a simple plural, "redistributables", clear the ambiguity for you ? It's hard to read that as "make the installed firmware redistributables" since it would be ungrammatical ... (I would understand if the devs balk.)
I don't think changing the flag name at this point would yield to any good result, unfortunately. I made my proposal earlier: making sure user sees the message (should be displayed as warning maybe) of excluded files when the flag is disabled.
(In reply to Pierre Asselin from comment #10) > @Georgi, Ilja: would a simple plural, "redistributables", clear the > ambiguity for you ? It's hard to read that as "make the installed firmware > redistributables" since it would be ungrammatical ... > > (I would understand if the devs balk.) I would vote yes, if that's the only option. At least it makes one wonder why the plural.
