Nis Martensen <nis.marten...@mailbox.org> writes: > On 18.05.2024 22.58, Xiyue Deng wrote: >> Using the use case in elpa-debian-el as an example, we handle CCing >> oneself in ELisp, so we assume reportbug is invoked without "list-cc-me" >> by not passing that argument. However, if the user has a >> "~/.reportbugrc" with "list-cc-me" in it, it will break this assumption, >> and reportbug ended up having it's own self CC and elpa-debian-el added >> another self CC, which would be confusing to users. If we have an >> option to disable loading "~/.reportbugrc" we can avoid this situation. > > Well, adding a way to override the "list-cc-me" would also avoid this > situation, wouldn't it?
This doesn't scale. What if there is another option that breaks the
assumption of elpa-debian-el? What if in the future reportbug adds
another option that changes another aspect of reportbug and breaks the
assumption of elpa-debian-el again? Being able to let reportbug behave
as if there is no other options are passed with minimum effort would
solve all the above.
> What I'm trying to discuss is the advantages and disadvantages of this
> alternative approach compared to your proposal.
Right on top of my head I can think of two alternative ways of doing the
same includes:
* For each option, provides an option to disable it, so that for an
option "--foo" there should be an option "--no-foo" to disable it.
- This leads to another question of when both "--foo" and "--no-foo"
as passed, which takes precedence? What if one of them is set in
"~/.reportbugrc"? In short, this option also doesn't scale.
* Provide a reportbug library and offer an API to query whether each
option is enabled or not.
- This doesn't really work for other programs that depends on using
reportbug through its command line interface, which currently means
every program that uses reportbug.
In short, I don't think those options are better than being able to
ignore "/etc/reportbug.conf" and "~/.reportbugrc"
> "Disable configuration files" seems like a very unspecific override
> (that might also break stuff other tools rely upon) to ask for if a
> more specific one would do.
I don't quite understand what you mean by "Disable configuration files"
being an unspecific override: it should give a default reportbug
behavior as if no other argument was passed to it except the ones
immediately done through the same command. Say if there were an option
"-q" to disable loading any configuration files, when I do "reportbug -q
--template" I don't have to worry about reportbug will behave as if I
was running "reportbug --template --list-cc-me" regardless of whether
there exists a "~/.reportbugrc" that has a line "list-cc-me" in it. I
believe this is very specific and makes reportbug behave
deterministically.
> Or maybe no change is actually needed at all, because your case is
> already resolved?
>
Technically nothing is actually resolved but just worked around: the
user has to remove the line "list-cc-me" in their "~/.reportbugrc",
which potentially makes it harder for them to use reportbug directly
from command line.
>> The same applies to other arguments that user may set but affect the
>> assumptions of other programs.
>
> I think it would be helpful if there was a real application use case to
> discuss here. If there aren't any (valid) assumptions by other programs
> that we are breaking then I don't think there is any bug and this should
> be closed.
>
OK. I don't really have an example of another such program yet. But at
least elpa-debian-el is a real program, and people are using it, which
is why we get bug reports like [1]. So IMHO it's not time to mark this
as closed yet.
> Since this is about cc-related options, are you already including the -x
> (or --no-cc) option when invoking reportbug? Reportbug doesn't actually
> read list-cc from its configuration file(s). It does read cc and list-cc-me.
As I mentioned, Bug#1069908 is about "--list-cc-me", and currently there
is no option to disable this option. And as I mentioned above with both
options available precedence becomes another problem to solve.
I think I didn't actually mention another point: implementing this is
trivial and potentially takes much less developer time compared to other
options I mentioned above. I'll try to work on an implementation in the
next few days and propose a merge request or patches for you to review,
if that's OK.
[1] https://bugs.debian.org/1069908
--
Xiyue Deng
signature.asc
Description: PGP signature
