Mailing List Archive

On Fri, Feb 9, 2024 at 10:23?AM Andrey Grozin
<grozin@woodpecker.gentoo.org> wrote:
>
> Hello *,
>
> pkgcheck complains about each new version of dev-lisp/sbcl:
>
> UseFlagWithoutDeps: version 2.4.1: special small-files USE flag without
> effect on dependencies: [ unicode ]
>
> The USE flag "unicode" in the sbcl ebuild has nothing to do with
> installing / not installing any files, small or otherwise. It determins
> whether the produced lisp will support unicode internally:
>
> sbcl_feature "$(usep unicode)" ":sb-unicode"
>
> Usually this is desirable, so, in USE we have +unicode. Is there a way to
> silence these warnings?

Is there some reason not to enable this unconditionally?

On Fri, Feb 09, 2024 at 03:23:10PM +0000, Andrey Grozin wrote:
> Hello *,
>
> pkgcheck complains about each new version of dev-lisp/sbcl:
>
> UseFlagWithoutDeps: version 2.4.1: special small-files USE flag without
> effect on dependencies: [ unicode ]
>
> The USE flag "unicode" in the sbcl ebuild has nothing to do with
> installing / not installing any files, small or otherwise. It determins
> whether the produced lisp will support unicode internally:
>
> sbcl_feature "$(usep unicode)" ":sb-unicode"
>
> Usually this is desirable, so, in USE we have +unicode. Is there a way to
> silence these warnings?

Is there even any reason to ever disable unicode support? Point is that
why have USE for it? Or does it introduce additional dependencies?
--
ionen

On Fri, 2024-02-09 at 10:54 -0500, Ionen Wolkens wrote:
>
> Is there even any reason to ever disable unicode support? Point is that
> why have USE for it? Or does it introduce additional dependencies?

Being able to disable things like this is one of the few reasons why
people choose Gentoo.

On Fri, Feb 9, 2024 at 11:07?AM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On Fri, 2024-02-09 at 10:54 -0500, Ionen Wolkens wrote:
> >
> > Is there even any reason to ever disable unicode support? Point is that
> > why have USE for it? Or does it introduce additional dependencies?
>
> Being able to disable things like this is one of the few reasons why
> people choose Gentoo.

Based on this pkgcheck issue, this originates from a decision from by
Gentoo QA team.

https://github.com/pkgcore/pkgcheck/issues/414#issuecomment-1213057268

On Fri, 2024-02-09 at 11:57 -0500, Mike Gilbert wrote:
>
> Based on this pkgcheck issue, this originates from a decision from by
> Gentoo QA team.
>
> https://github.com/pkgcore/pkgcheck/issues/414#issuecomment-1213057268
>

Thanks for the dig. I agree with the reasoning for things like
USE=bash-completion and USE=vim-syntax, where the added complexity of a
flag is not justified to avoid installing small files. In those cases,
the additional files simply don't do anything if you don't (for
example) use vim.

USE=unicode and USE=ipv6 are different beasts. In many cases they
directly and immediately change the behavior of the package. I think
that there are good reasons to want those two disabled, but the user's
reasoning shouldn't really matter. The only "problem" in this case is
the pkgcheck warning. Upstream supports it, the maintainer supports it,
it works, users might want it, and it's one of our selling points.
Given all of that, I'm leery of treating it like some kind of mistake.

On Fri, Feb 9, 2024 at 12:17?PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On Fri, 2024-02-09 at 11:57 -0500, Mike Gilbert wrote:
> >
> > Based on this pkgcheck issue, this originates from a decision from by
> > Gentoo QA team.
> >
> > https://github.com/pkgcore/pkgcheck/issues/414#issuecomment-1213057268
> >
>
> Thanks for the dig. I agree with the reasoning for things like
> USE=bash-completion and USE=vim-syntax, where the added complexity of a
> flag is not justified to avoid installing small files. In those cases,
> the additional files simply don't do anything if you don't (for
> example) use vim.
>
> USE=unicode and USE=ipv6 are different beasts. In many cases they
> directly and immediately change the behavior of the package.

In most cases I have seen, it makes more sense to toggle the behavior
at runtime rather than disabling functionality at build time.

Exposing build flags for stuff that can be toggled at runtime is added
complexity for little benefit. It sometimes even makes maintaining the
ebuild and dependent packages more difficult.

On 2/9/24 12:17 PM, Michael Orlitzky wrote:
> USE=unicode and USE=ipv6 are different beasts. In many cases they
> directly and immediately change the behavior of the package. I think
> that there are good reasons to want those two disabled, but the user's
> reasoning shouldn't really matter. The only "problem" in this case is
> the pkgcheck warning. Upstream supports it, the maintainer supports it,
> it works, users might want it, and it's one of our selling points.
> Given all of that, I'm leery of treating it like some kind of mistake.


Asking out of genuine ignorance: what kind of direct behavioral changes
occur as a result of setting or unsetting USE=ipv6.

I'm assuming that:

- users who don't want ipv6 are also masking it in the kernel at
runtime

- users who do want ipv6 consider it a bug if the direct and immediate
change is that the software is "broken because it fails due to lack of
ipv6 support"

Along a similar line: I've never touched sbcl so again, I have *no* clue
what its deal is and am just curious: what are the advantages and
disadvantages of setting USE=unicode on it? In particular since it
defaults to on, under what circumstances would someone wish to unset it?

"There are good reasons" is pretty vague. I assume the reason is more
interesting than "when it is disabled, the package is buggy and broken
for certain use cases which the user has explicitly chosen to not care
about".

Does it make the package smaller?

Does it avoid depending on additional packages? (no...)

Are unicode strings sometimes bad to have, but users cannot choose the
string type except by recompiling the programming language itself? (Okay
if that is the case, but that seems a strange decision for a programming
language to make...)


--
Eli Schwartz

On Fri, 2024-02-09 at 14:09 -0500, Eli Schwartz wrote:
>
> Asking out of genuine ignorance: what kind of direct behavioral changes
> occur as a result of setting or unsetting USE=ipv6.

One example I know off the top of my head is dev-lang/php where
USE=ipv6 isn't entirely about ipv6 connectivity (although it does do
that). It also augments some of the user-facing PHP language functions
with ipv6 support. Having them enabled is not a big deal, and PHP is a
programming language so you may say that it's atypical, but... for a
package that gets a new CVE every week and sits on the public web, I'd
just rather have it off?

Unicode support is similar in my mind. Adding "unicode support" to a
package might be easy (at the cost of some extra memory), but dealing
with the consequences of unicode is harder. Maybe I don't want to worry
about homoglyphs and bidirectional text when I'm validating a hostname?
Life is just simpler without it, if you know you don't need it. Things
also tend to be more space and memory efficient with features compiled
out; not to mention that the compile times themselves are improved.
You're still pulling in "extra dependencies," in a sense, even if
they're in the same tarball.

I really don't want to fall into a trap where I make up reasons why
other people might want to do things and everyone says my reasons are
stupid. Everyone is going to have different reasons, and we have a lot
of users who are our users because they're edge cases.

It's not unfathomably stupid to build a package without ipv6 or unicode
support (whatever that means), and there are no small files to worry
about, so I don't think they deserve the special negative treatment.

On 2/9/24 2:57 PM, Michael Orlitzky wrote:
> One example I know off the top of my head is dev-lang/php where
> USE=ipv6 isn't entirely about ipv6 connectivity (although it does do
> that). It also augments some of the user-facing PHP language functions
> with ipv6 support. Having them enabled is not a big deal, and PHP is a
> programming language so you may say that it's atypical, but... for a
> package that gets a new CVE every week and sits on the public web, I'd
> just rather have it off?


Counterpoint: some PHP program out there is probably vulnerable because
it tried to validate an ipv6 address and could not distinguish between
"it's okay" and "idk if it's okay, the function you called does not
exist" (because php is really that terrible of a language).

I'm confused why you think compiling or not compiling in support for
part of a programming language is supposed to make CVEs *less* likely to
happen, rather than more likely?

In the most optimistic scenario, it's a denial of service CVE because
part of the programming language got deleted, instead of a remote code
execution vulnerability because the application didn't correctly handle
the consequences of silently returning NULL.


> Unicode support is similar in my mind. Adding "unicode support" to a
> package might be easy (at the cost of some extra memory), but dealing
> with the consequences of unicode is harder. Maybe I don't want to worry
> about homoglyphs and bidirectional text when I'm validating a hostname?
> Life is just simpler without it, if you know you don't need it.


... and this is a property of the way you build the programming language
rather than your choice of APIs when you compile your own software
*using* sbcl?


> Things
> also tend to be more space and memory efficient with features compiled
> out; not to mention that the compile times themselves are improved.
> You're still pulling in "extra dependencies," in a sense, even if
> they're in the same tarball.


That sounds trivial to demonstrate. Can you describe the timings on how
long a src_compile takes with and without this USE flag? What is the
resulting size of the package?

I will note that using -march=native also has an effect on compile time,
and space and memory efficiency. But it is a feature of your CFLAGS, not
USE.

This invites another thought, for me. Gentoo doesn't necessarily need to
support every possible option, since package.env can set EXTRA_ECONF,
MYMESONARGS, MYCMAKEARGS.

eclass-based overrides, too, are part of "Gentoo is about choice". I use
this myself for things that aren't controllable as USE flags.


> I really don't want to fall into a trap where I make up reasons why
> other people might want to do things and everyone says my reasons are
> stupid. Everyone is going to have different reasons, and we have a lot
> of users who are our users because they're edge cases.
>
> It's not unfathomably stupid to build a package without ipv6 or unicode
> support (whatever that means), and there are no small files to worry
> about, so I don't think they deserve the special negative treatment.


Maintainability matters too. So does user experience in the other
direction: too many USE flags will lead users to confusion if they don't
understand what all those flags do, and accidentally choose the wrong
answer.

That's not necessarily a reason to remove choice, so much as it is a
reason to... carefully document what that choice actually gets you.

$ equery -N uses sbcl | grep unicode
+ + unicode : Add support for Unicode


This is... vague. Good to know that it is enabled by default, but...
what? What does it do? There is no description in metadata.xml, either.

I think it is fair and reasonable for people to ask people's reasons are
for doing something when it is not actually obvious what the point is.
And when a USE flag selects or deselects dependencies, it is very easy
to know, what exactly "the point" is.

Often, USE flags have an obvious point even without selecting or
deselecting dependencies -- usually because their maintainers took care
in describing it in metadata.xml.


If people disagree about the specific choice itself, that's one thing
(and Gentoo values respecting all sides, though not unconditionally so
-- see libressl and eudev for examples where choice was booted out of
::gentoo, and people were told they'd have to homebrew their own
overlays if they wanted that choice).

It's another thing entirely when people cannot see what the choice
actually is, and start suspecting that there is no choice, "the choice
is a lie".


--
Eli Schwartz

On Fri, 2024-02-09 at 16:04 -0500, Eli Schwartz wrote:
>
> Counterpoint: some PHP program out there is probably vulnerable because
> it tried to validate an ipv6 address and could not distinguish between
> "it's okay" and "idk if it's okay, the function you called does not
> exist" (because php is really that terrible of a language).
>
> I'm confused why you think compiling or not compiling in support for
> part of a programming language is supposed to make CVEs *less* likely to
> happen, rather than more likely?

This is the part where you try to convince me that the things I want
are stupid. OK. I don't care. I want it off. Leave me alone :)

On 2/9/24 4:25 PM, Michael Orlitzky wrote:
> This is the part where you try to convince me that the things I want
> are stupid. OK. I don't care. I want it off. Leave me alone :)


As evidenced by the removal of libressl and eudev, this logic is
fallacious and wrong and not the way Gentoo is developed.

Gentoo does indeed discuss the things that people want, and try to
determine whether they are useful to users, whether they are a placebo,
and whether they are maintainable or have an adverse effect either on
users or on the effort to maintain a consistent tree.

So circling back around to the start of the thread:

> pkgcheck complains about each new version of dev-lisp/sbcl:

It is the allegation of the QA team that the option is a lie, it
contains no purpose or value and doesn't contribute to use choice, and
pkgcheck is reporting the QA team's allegation.

If you wish to convince the QA team otherwise, be my guest... but I
would personally encourage you to come up with a better argument than
"the option makes me feel better about myself, I don't care what you
have to say, just leave my options alone goshdarnit; I have the right to
be stupid".

Because I don't think you're likely to convince anyone like that. Sorry.


--
Eli Schwartz

On 2024-02-09 21:56, Eli Schwartz wrote:
> On 2/9/24 4:25 PM, Michael Orlitzky wrote:
>> This is the part where you try to convince me that the things I want
>> are stupid. OK. I don't care. I want it off. Leave me alone :)
>
>
> As evidenced by the removal of libressl and eudev, this logic is
> fallacious and wrong and not the way Gentoo is developed.
>

Both removals definitely not still being contested and debated.

> Gentoo does indeed discuss the things that people want, and try to
> determine whether they are useful to users, whether they are a placebo,
> and whether they are maintainable or have an adverse effect either on
> users or on the effort to maintain a consistent tree.
>
> So circling back around to the start of the thread:
>
>> pkgcheck complains about each new version of dev-lisp/sbcl:
>
> It is the allegation of the QA team that the option is a lie, it
> contains no purpose or value and doesn't contribute to use choice, and
> pkgcheck is reporting the QA team's allegation.
>
> If you wish to convince the QA team otherwise, be my guest... but I
> would personally encourage you to come up with a better argument than
> "the option makes me feel better about myself, I don't care what you
> have to say, just leave my options alone goshdarnit; I have the right
> to
> be stupid".
>
> Because I don't think you're likely to convince anyone like that.
> Sorry.

Maybe support as much choice as possible, and not act like you know what
users want better that the users themselves.

--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=64
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji"

Andrey Grozin <grozin@woodpecker.gentoo.org> writes:

> Hello *,
>
> pkgcheck complains about each new version of dev-lisp/sbcl:
>
> UseFlagWithoutDeps: version 2.4.1: special small-files USE flag
> without effect on dependencies: [ unicode ]
>
> The USE flag "unicode" in the sbcl ebuild has nothing to do with
> installing / not installing any files, small or otherwise. It
> determins whether the produced lisp will support unicode internally:
>
> sbcl_feature "$(usep unicode)" ":sb-unicode"
>
> Usually this is desirable, so, in USE we have +unicode.
>

If you can't think of a someone to not want it, you should just enable
it. Common reasons to not want it are substantial impact on build-time,
additional dependencies, unsupported or poorly supported upstream,
experimental status, and so on.

Most of the time, one of these applies for these flags, and it's
therefore useless. Hence https://github.com/pkgcore/pkgcheck/issues/414.

Note further that USE=unicode is forced on for many packages in profiles
and historically it ended up changing ABI for a bunch of them.

If you conclude that there is a valid reason to toggle it, then the
next part becomes relevant:

> Is there a way to silence these warnings?

There are real times when we may want to suppress the
warning/notices. This is tracked as
https://github.com/pkgcore/pkgcheck/issues/478
for pkgcheck.

thanks,
sam

Michael Orlitzky <mjo@gentoo.org> writes:

> On Fri, 2024-02-09 at 14:09 -0500, Eli Schwartz wrote:
>>
>> Asking out of genuine ignorance: what kind of direct behavioral changes
>> occur as a result of setting or unsetting USE=ipv6.
>
> One example I know off the top of my head is dev-lang/php where
> USE=ipv6 isn't entirely about ipv6 connectivity (although it does do
> that). It also augments some of the user-facing PHP language functions
> with ipv6 support. Having them enabled is not a big deal, and PHP is a
> programming language so you may say that it's atypical, but... for a
> package that gets a new CVE every week and sits on the public web, I'd
> just rather have it off?

A few years ago when this last came up, I ended up digging into a bunch
of USE=ipv6 providers and found that USE=-ipv6 either didn't build, took
a less supported (non-default-upstream) codepath which looked bitrotten,
only toggled default configuration (sometimes via the build system). I
also found several cases where it ended up taking a legacy code path
while the USE=ipv6 one used modern networking functions which happened to then
support IPv6.

For a case like the latter one (and the rest I mention, really),
disabilng kernel support is more appropriate.

But read on wrt PHP.

>
> Unicode support is similar in my mind. Adding "unicode support" to a
> package might be easy (at the cost of some extra memory), but dealing
> with the consequences of unicode is harder. Maybe I don't want to worry
> about homoglyphs and bidirectional text when I'm validating a hostname?
> Life is just simpler without it, if you know you don't need it. Things
> also tend to be more space and memory efficient with features compiled
> out; not to mention that the compile times themselves are improved.
> You're still pulling in "extra dependencies," in a sense, even if
> they're in the same tarball.

I think what you really want is
https://github.com/pkgcore/pkgcheck/issues/478 because you've made the
case as its maintainer for the flags to exist. The discussion really
ends there in such a case given you're considered the matter and decided
it has value in PHP.

The issue is therefore just having a suppression for pkgcheck. The
pkgcheck rule was intended as a hint that something might be suspicious,
rather than indicating it must be removed.

thanks,
sam

On 10/2/24 08:56, stefan11111 wrote:
> Both removals definitely not still being contested and debated.

You've conveniently ignored the context immediately below the line that
you chose to quote and somehow decided to try and shoehorn in discussion
of a completely different (and settled) issue. Congratulations, it's not
often that I get to open my emails in the morning and untangle several
different flavours of wrong in only a single line!

> Maybe support as much choice as possible, and not act like you know what
> users want better that the users themselves.

FYI I don't appreciate your tone. Purge it down a little next time,
please?

Knowing what's best for users, especially when the users in question
appear to be willfully misinformed, is actually part of a developer's
job description. We even have a fancy section of the dev manual that's
all about not adding superfluous USE flags because we've learnt through
experience that providing a toggle for every single little thing in a
package is not, in fact, beneficial to users overall.

https://devmanual.gentoo.org/general-concepts/use-flags/index.html#when-not-to-use-use-flags

Users _rely_ on developers to make sane decisions on their behalf,
particularly around which USE options should exist and be togglable and
which options it makes sense to just hard enable or disable in the
configure step. In general we don't expect users to have an in-depth
knowledge of an upstream build system; they don't need to be across the
implementation details of every single configure option, they just need
to trust the options enabled by ebuild developers (and by extension the
decisions made by the wider project, including [and especially] areas
like QA).

In addition to this there are mechanisms through which a user can choose
to override the decisions made within an ebuild, including but not
limited to the already-mentioned EXTRA_ECONF, MYMESONARGS, MYCMAKEARGS
in package.env.

TL;DR: Methinks thou dost make too great a mountain of that which is but
a molehill

On to the main subject, we already default USE=unicode to on in the
ebuild and a browse over the sbcl docs suggests that it's also the
upstream default and is unlikely to break anything given that it's been
that way since version 0.8.17 and we're well into major version 2 by
now. Just drop the USE and default it to on - QA is right in this case:
in the absence of a compelling reason to keep the USE it should be
dropped.

Cheers,

Matt

Eli Schwartz <eschwartz93@gmail.com> writes:

> [[PGP Signed Part:Undecided]]
> On 2/9/24 2:57 PM, Michael Orlitzky wrote:
>> One example I know off the top of my head is dev-lang/php where
>> USE=ipv6 isn't entirely about ipv6 connectivity (although it does do
>> that). It also augments some of the user-facing PHP language functions
>> with ipv6 support. Having them enabled is not a big deal, and PHP is a
>> programming language so you may say that it's atypical, but... for a
>> package that gets a new CVE every week and sits on the public web, I'd
>> just rather have it off?
>
>
> Counterpoint: some PHP program out there is probably vulnerable because
> it tried to validate an ipv6 address and could not distinguish between
> "it's okay" and "idk if it's okay, the function you called does not
> exist" (because php is really that terrible of a language).
>

I was going to make this point as well but I didn't want to go down that
route as I figured it'd come across like I'm questioning Michael, as
oppossed to trying to make a point about using an option simply because
it exists.

i.e. Disabling an option isn't always as simple as it sounds (see
below).

But I'm also not personally wanting to debate that PHP should remove it,
just saying that this sort of consideration should be made and it's part
of why a USE flag for everything is not always great.

We *HAVE* had real problems like this before, see also USE=threads
(check out commit bd4d42f83c774c36bf879a5b7ec89d373546743e).

> [...]
>> I really don't want to fall into a trap where I make up reasons why
>> other people might want to do things and everyone says my reasons are
>> stupid. Everyone is going to have different reasons, and we have a lot
>> of users who are our users because they're edge cases.
>>
>> It's not unfathomably stupid to build a package without ipv6 or unicode
>> support (whatever that means), and there are no small files to worry
>> about, so I don't think they deserve the special negative treatment.
>
>
> Maintainability matters too. So does user experience in the other
> direction: too many USE flags will lead users to confusion if they don't
> understand what all those flags do, and accidentally choose the wrong
> answer.


also whether the flag then gets tinderboxed, reverse dependencies having
to depend on the right flags, debugging user issues which may not be
obvious (especially if they surface in another application/interface)
because of it...

(It's also worth us having the discussion about whether a flag existing
means a tinderbox should try it, e.g. USE=debug which IMO isn't suitable
for this at all (see also its description) and the kernel stuff like for
secureboot.)

>
> That's not necessarily a reason to remove choice, so much as it is a
> reason to... carefully document what that choice actually gets you.
>
> $ equery -N uses sbcl | grep unicode
> + + unicode : Add support for Unicode
>
>
> This is... vague. Good to know that it is enabled by default, but...
> what? What does it do? There is no description in metadata.xml, either.
>
> I think it is fair and reasonable for people to ask people's reasons are
> for doing something when it is not actually obvious what the point is.
> And when a USE flag selects or deselects dependencies, it is very easy
> to know, what exactly "the point" is.
>
> Often, USE flags have an obvious point even without selecting or
> deselecting dependencies -- usually because their maintainers took care
> in describing it in metadata.xml.
>

To pick up on this point: yes, if one concludes the USE flag has merit
and the global description is either poor or has some reason to be
considered spurious in the case of the package, you should consider
documenting it to avoid this question.

Adding a suppression like https://github.com/pkgcore/pkgcheck/issues/478
proposes should really be accompanied by such an improvement anyway for
the benefit of users.

On Fri, 9 Feb 2024 16:56:55 -0500
Eli Schwartz <eschwartz93@gmail.com> wrote:

> On 2/9/24 4:25 PM, Michael Orlitzky wrote:
> > This is the part where you try to convince me that the things I want
> > are stupid. OK. I don't care. I want it off. Leave me alone :)
>
>
> As evidenced by the removal of libressl and eudev, this logic is
> fallacious and wrong and not the way Gentoo is developed.

Fwiw I still use both and Gentoo removing specifically Libressl has
only been detrimental. There is a huge amount of extra and redundant
maintainer work when all of the fixes have to be applied over and over
again without changes as the main Gentoo repo gets updated. Its
relatively rare that the fixes have to be rebased or changed against
their respective upstream, but rebasing it against Gentoo is an
extremely common and tedious task.

Your argument is invalid and not appreciated.

>
> Gentoo does indeed discuss the things that people want, and try to
> determine whether they are useful to users, whether they are a
> placebo, and whether they are maintainable or have an adverse effect
> either on users or on the effort to maintain a consistent tree.
>
> So circling back around to the start of the thread:
>
> > pkgcheck complains about each new version of dev-lisp/sbcl:
>
> It is the allegation of the QA team that the option is a lie, it
> contains no purpose or value and doesn't contribute to use choice, and
> pkgcheck is reporting the QA team's allegation.
>
> If you wish to convince the QA team otherwise, be my guest... but I
> would personally encourage you to come up with a better argument than
> "the option makes me feel better about myself, I don't care what you
> have to say, just leave my options alone goshdarnit; I have the right
> to be stupid".
>
> Because I don't think you're likely to convince anyone like that.
> Sorry.
>
>

On Fri, 2024-02-09 at 22:56 +0000, stefan11111 wrote:
> On 2024-02-09 21:56, Eli Schwartz wrote:
> > On 2/9/24 4:25 PM, Michael Orlitzky wrote:
> > > This is the part where you try to convince me that the things I
> > > want
> > > are stupid. OK. I don't care. I want it off. Leave me alone :)
> >
> >
> > As evidenced by the removal of libressl and eudev, this logic is
> > fallacious and wrong and not the way Gentoo is developed.
> >
>
> Both removals definitely not still being contested and debated.
>
> > Gentoo does indeed discuss the things that people want, and try to
> > determine whether they are useful to users, whether they are a
> > placebo,
> > and whether they are maintainable or have an adverse effect either
> > on
> > users or on the effort to maintain a consistent tree.
> >
> > So circling back around to the start of the thread:
> >
> > > pkgcheck complains about each new version of dev-lisp/sbcl:
> >
> > It is the allegation of the QA team that the option is a lie, it
> > contains no purpose or value and doesn't contribute to use choice,
> > and
> > pkgcheck is reporting the QA team's allegation.
> >
> > If you wish to convince the QA team otherwise, be my guest... but I
> > would personally encourage you to come up with a better argument
> > than
> > "the option makes me feel better about myself, I don't care what you
> > have to say, just leave my options alone goshdarnit; I have the
> > right
> > to
> > be stupid".
> >
> > Because I don't think you're likely to convince anyone like that.
> > Sorry.
>
> Maybe support as much choice as possible, and not act like you know
> what
> users want better that the users themselves.
>

Are users like you going to maintain and fix these obscure bugs too? I
don't recall seeing you sending in many fixes or patches, yet you seem
to be demanding that we go out of our way to accommodate you.

On 2024-02-10 11:48, David Seifert wrote:
>
> Are users like you going to maintain and fix these obscure bugs too? I
> don't recall seeing you sending in many fixes or patches, yet you seem
> to be demanding that we go out of our way to accommodate you.

I've sent and made plenty of patches to support my use cases.
I usually don't send patches to the ml and instead link them in bug
reports, forum posts, etc.

Feel free to pull patches from my overlay or any other repo I have:
https://github.com/stefan11111/stefan_overlay/
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz

COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=64
-fgraphite-identity -floop-nest-optimize"

USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"

INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji"

On 2/9/24 7:04 PM, Sam James wrote:
>
> Eli Schwartz <eschwartz93@gmail.com> writes:
>> Often, USE flags have an obvious point even without selecting or
>> deselecting dependencies -- usually because their maintainers took care
>> in describing it in metadata.xml.
>>
>
> To pick up on this point: yes, if one concludes the USE flag has merit
> and the global description is either poor or has some reason to be
> considered spurious in the case of the package, you should consider
> documenting it to avoid this question.
>
> Adding a suppression like https://github.com/pkgcore/pkgcheck/issues/478
> proposes should really be accompanied by such an improvement anyway for
> the benefit of users.


I'd like to request in the event that this pkgcheck ticket is
implemented, that including a description in metadata.xml which provides
additional package specific information (or, programmatically, "is
non-empty and un-equal to the global description") is made mandatory for
the purposes of silencing this warning... :)


--
Eli Schwartz

On 2/10/24 6:22 AM, orbea wrote:
> On Fri, 9 Feb 2024 16:56:55 -0500
> Eli Schwartz <eschwartz93@gmail.com> wrote:
>> As evidenced by the removal of libressl and eudev, this logic is
>> fallacious and wrong and not the way Gentoo is developed.
>
> Fwiw I still use both and Gentoo removing specifically Libressl has
> only been detrimental. There is a huge amount of extra and redundant
> maintainer work when all of the fixes have to be applied over and over
> again without changes as the main Gentoo repo gets updated. Its
> relatively rare that the fixes have to be rebased or changed against
> their respective upstream, but rebasing it against Gentoo is an
> extremely common and tedious task.
>
> Your argument is invalid and not appreciated.


Sorry, could you clarify what you mean by this?

I made a comment about the facts of reality regarding how Gentoo *is*
developed. I understand that this has posed challenges to you and makes
your work harder. Nonetheless, my statement about facts and realities is
true: Gentoo really did remove upstream tree support for both from the
::gentoo tree.

What, therefore, is "invalid" about my argument? Are you writing to the
mailing list to inform me that my understanding of reality is invalid,
and that contrary to my belief, the ::gentoo tree *does* officially
support (and package!) libressl and eudev?


--
Eli Schwartz

On 2/10/24 12:26 PM, stefan11111 wrote:
> On 2024-02-10 11:48, David Seifert wrote:
>>
>> Are users like you going to maintain and fix these obscure bugs too? I
>> don't recall seeing you sending in many fixes or patches, yet you seem
>> to be demanding that we go out of our way to accommodate you.
>
> I've sent and made plenty of patches to support my use cases.
> I usually don't send patches to the ml and instead link them in bug
> reports, forum posts, etc.
>
> Feel free to pull patches from my overlay or any other repo I have:
> https://github.com/stefan11111/stefan_overlay/


From every patch you've demonstrated in the past, my overall impression
is that you put zero effort into attempting to convince others, zero
effort into making the patches capable of supporting the toggleable use
case (no, commenting out lines wholesale is not a suitable patch, adding
a build option and an ifelse would be) and basically, in short...

... you've behaved in a way that guarantees that no patches of yours
will ever be merged upstream.

This is personally sad to me because I actually do think a number of
them would make good toggleable feature options for upstream.


--
Eli Schwartz

Eli Schwartz <eschwartz93@gmail.com> writes:

> [[PGP Signed Part:Undecided]]
> On 2/9/24 7:04 PM, Sam James wrote:
>>
>> Eli Schwartz <eschwartz93@gmail.com> writes:
>>> Often, USE flags have an obvious point even without selecting or
>>> deselecting dependencies -- usually because their maintainers took care
>>> in describing it in metadata.xml.
>>>
>>
>> To pick up on this point: yes, if one concludes the USE flag has merit
>> and the global description is either poor or has some reason to be
>> considered spurious in the case of the package, you should consider
>> documenting it to avoid this question.
>>
>> Adding a suppression like https://github.com/pkgcore/pkgcheck/issues/478
>> proposes should really be accompanied by such an improvement anyway for
>> the benefit of users.
>
>
> I'd like to request in the event that this pkgcheck ticket is
> implemented, that including a description in metadata.xml which provides
> additional package specific information (or, programmatically, "is
> non-empty and un-equal to the global description") is made mandatory for
> the purposes of silencing this warning... :)

parona ended up messaging me and pointing out that
https://pkgcore.github.io/pkgcheck/man/pkgcheck.html#useflagwithoutdeps
already says...

> In cases where this USE flag is appropriate, you can silence this
> warning by adding a description to this USE flag in metadata.xml file
> and thus making it a local USE flag instead of global one.

which I think pretty much solves the full thing already...

On 2/10/24 10:46 PM, Sam James wrote:
> parona ended up messaging me and pointing out that
> https://pkgcore.github.io/pkgcheck/man/pkgcheck.html#useflagwithoutdeps
> already says...
>
>> In cases where this USE flag is appropriate, you can silence this
>> warning by adding a description to this USE flag in metadata.xml file
>> and thus making it a local USE flag instead of global one.
>
> which I think pretty much solves the full thing already...


I was kind of hoping (in lieu of reading man pages) that someone would
try it simply because it's the right thing to do and then get a happy
surprise upon seeing that pkgcheck had excellent forethought.


--
Eli Schwartz