Hi All,
What is wrong with my wine dnf excludes?
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
dnf still tried to upgrade wine!!!!
And wine 8 IS EVEN WORSE THAN WINE 7!!!!
Wine 8.0.1 cannot print to a local printer, but can to a network printer https://bugs.winehq.org/show_bug.cgi?id=54428
I need to stay on wine 6 and also be able to update everything else.
Many thanks, -T
On Thu, Feb 2, 2023 at 12:55 AM ToddAndMargo via users users@lists.fedoraproject.org wrote:
What is wrong with my wine dnf excludes?
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
dnf still tried to upgrade wine!!!!
And wine 8 IS EVEN WORSE THAN WINE 7!!!!
Wine 8.0.1 cannot print to a local printer, but can to a network printer https://bugs.winehq.org/show_bug.cgi?id=54428
I need to stay on wine 6 and also be able to update everything else.
It seems like you want to versionlock, and not exclude, wine.
Maybe something like https://unix.stackexchange.com/a/606854 ?
Jeff
On 2/1/23 22:01, Jeffrey Walton wrote:
On Thu, Feb 2, 2023 at 12:55 AM ToddAndMargo via users users@lists.fedoraproject.org wrote:
What is wrong with my wine dnf excludes?
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
dnf still tried to upgrade wine!!!!
And wine 8 IS EVEN WORSE THAN WINE 7!!!!
Wine 8.0.1 cannot print to a local printer, but can to a network printer https://bugs.winehq.org/show_bug.cgi?id=54428
I need to stay on wine 6 and also be able to update everything else.
It seems like you want to versionlock, and not exclude, wine.
Maybe something like https://unix.stackexchange.com/a/606854 ?
Jeff
I never had any trouble with my excludes under Fedora 36. This occurred since Fedora 37. Hmmmmm.........
On 2/1/23 23:05, Joe Zeff wrote:
On 02/01/2023 10:55 PM, ToddAndMargo via users wrote:
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
The second exclude should be redundant, as it's already covered by the first one. That doesn't explain what's going on, but I did want to mention it.
I think the second one *replaces* the first one. There's no indication that it would accumulate.
On 2/2/23 22:26, Samuel Sieb wrote:
On 2/1/23 23:05, Joe Zeff wrote:
On 02/01/2023 10:55 PM, ToddAndMargo via users wrote:
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
The second exclude should be redundant, as it's already covered by the first one. That doesn't explain what's going on, but I did want to mention it.
I think the second one *replaces* the first one. There's no indication that it would accumulate.
I have tried to with and without
On Wed, 2023-02-01 at 21:55 -0800, ToddAndMargo via users wrote:
What is wrong with my wine dnf excludes?
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
dnf still tried to upgrade wine!!!!
Does the asterisk need escaping, there?
e.g. wine*
I didn't think it did, just on the command line.
On 2/1/23 21:55, ToddAndMargo via users wrote:
What is wrong with my wine dnf excludes?
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
dnf still tried to upgrade wine!!!!
I bet you have some other excludepkgs lines after that. Only the last one takes effect. I just tested it and "excludepkgs=wine*" stops even "dnf upgrade wine*".
On 2/2/23 22:29, Samuel Sieb wrote:
On 2/1/23 21:55, ToddAndMargo via users wrote:
What is wrong with my wine dnf excludes?
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
dnf still tried to upgrade wine!!!!
I bet you have some other excludepkgs lines after that. Only the last one takes effect. I just tested it and "excludepkgs=wine*" stops even "dnf upgrade wine*".
Here is the whole thing, which worked under fc36:
$ cat /etc/dnf/dnf.conf [main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True excludepkgs=metasploit-framework # excludepkgs=metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework excludepkgs=wine* # excludepkgs=wine-* excludepkgs=resolvconf excludepkgs=systemd-resolved
OH GET A LOAD OF THIS!!!!
# dnf upgrade --excludepkgs=wine*
Works!!!
AAAAAAHHHHHH !!!!!!
On 2/3/23 18:13, ToddAndMargo via users wrote:
On 2/2/23 22:29, Samuel Sieb wrote:
On 2/1/23 21:55, ToddAndMargo via users wrote:
What is wrong with my wine dnf excludes?
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
dnf still tried to upgrade wine!!!!
I bet you have some other excludepkgs lines after that. Only the last one takes effect. I just tested it and "excludepkgs=wine*" stops even "dnf upgrade wine*".
Here is the whole thing, which worked under fc36:
$ cat /etc/dnf/dnf.conf [main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True excludepkgs=metasploit-framework # excludepkgs=metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework excludepkgs=wine* # excludepkgs=wine-* excludepkgs=resolvconf excludepkgs=systemd-resolved
OH GET A LOAD OF THIS!!!!
# dnf upgrade --excludepkgs=wine*
Works!!!
AAAAAAHHHHHH !!!!!!
I just enter the following bug report:
dnf.conf excludepkgs=wine* no longer works https://bugzilla.redhat.com/show_bug.cgi?id=2167036
ToddAndMargo via users wrote:
On 2/2/23 22:29, Samuel Sieb wrote:
On 2/1/23 21:55, ToddAndMargo via users wrote:
What is wrong with my wine dnf excludes?
# grep -i wine /etc/dnf/dnf.conf excludepkgs=wine* excludepkgs=wine-*
dnf still tried to upgrade wine!!!!
I bet you have some other excludepkgs lines after that. Only the last one takes effect.
You should take heed of Samuel's words above.
Here is the whole thing, which worked under fc36:
I don't find this to be true. Testing it locally, it fails just as I'd expect and as the documentation suggests.
$ cat /etc/dnf/dnf.conf [main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True excludepkgs=metasploit-framework # excludepkgs=metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework excludepkgs=wine* # excludepkgs=wine-* excludepkgs=resolvconf excludepkgs=systemd-resolved
This is not the way I've ever seen excludepkgs used or documented. The man page states:
excludepkgs list
Exclude packages of this repository, speci‐ fied by a name or a glob and separated by a comma, from all operations. Can be disabled using --disableexcludes command line switch. Defaults to [].
Put them all together, not a bunch of different definitions.
On Fri, Feb 3, 2023 at 10:11 PM Todd Zullinger tmz@pobox.com wrote:
ToddAndMargo via users wrote:
On 2/2/23 22:29, Samuel Sieb wrote:
On 2/1/23 21:55, ToddAndMargo via users wrote:
$ cat /etc/dnf/dnf.conf [main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True excludepkgs=metasploit-framework # excludepkgs=metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework excludepkgs=wine* # excludepkgs=wine-* excludepkgs=resolvconf excludepkgs=systemd-resolved
This is not the way I've ever seen excludepkgs used or documented. The man page states:
excludepkgs list Exclude packages of this repository, speci‐ fied by a name or a glob and separated by a comma, from all operations. Can be disabled using --disableexcludes command line switch. Defaults to [].
Put them all together, not a bunch of different definitions.
Note: "separated by a comma" - the commented-out lines were separated by spaces (I assume these were failed attempts).
On 2/3/23 20:10, Go Canes wrote:
On Fri, Feb 3, 2023 at 10:11 PM Todd Zullinger tmz@pobox.com wrote:
ToddAndMargo via users wrote:
On 2/2/23 22:29, Samuel Sieb wrote:
On 2/1/23 21:55, ToddAndMargo via users wrote:
$ cat /etc/dnf/dnf.conf [main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True excludepkgs=metasploit-framework # excludepkgs=metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework wine* # excludepkgs=thunderbird* metasploit-framework excludepkgs=wine* # excludepkgs=wine-* excludepkgs=resolvconf excludepkgs=systemd-resolved
This is not the way I've ever seen excludepkgs used or documented. The man page states:
excludepkgs list Exclude packages of this repository, speci‐ fied by a name or a glob and separated by a comma, from all operations. Can be disabled using --disableexcludes command line switch. Defaults to [].
Put them all together, not a bunch of different definitions.
Note: "separated by a comma" - the commented-out lines were separated by spaces (I assume these were failed attempts).
excludepkgs=wine*,resolvconf,systemd-resolved
Did work. I missed what Samuel's said.
This is a regression from Fedora 36. I updates the bug report.
On 2/3/23 21:32, ToddAndMargo via users wrote:
On 2/3/23 20:10, Go Canes wrote:
On Fri, Feb 3, 2023 at 10:11 PM Todd Zullinger tmz@pobox.com wrote:
This is not the way I've ever seen excludepkgs used or documented. The man page states:
excludepkgs list
Exclude packages of this repository, speci‐ fied by a name or a glob and separated by a comma, from all operations. Can be disabled using --disableexcludes command line switch. Defaults to [].
Put them all together, not a bunch of different definitions.
Note: "separated by a comma" - the commented-out lines were separated by spaces (I assume these were failed attempts).
excludepkgs=wine*,resolvconf,systemd-resolved
Did work. I missed what Samuel's said.
This is a regression from Fedora 36. I updates the bug report.
It might be a change, but it's not a regression. It's clearly documented in the man page.
On 2/4/23 00:05, Samuel Sieb wrote:
On 2/3/23 21:32, ToddAndMargo via users wrote:
On 2/3/23 20:10, Go Canes wrote:
On Fri, Feb 3, 2023 at 10:11 PM Todd Zullinger tmz@pobox.com wrote:
This is not the way I've ever seen excludepkgs used or documented. The man page states:
excludepkgs list
Exclude packages of this repository, speci‐ fied by a name or a glob and separated by a comma, from all operations. Can be disabled using --disableexcludes command line switch. Defaults to [].
Put them all together, not a bunch of different definitions.
Note: "separated by a comma" - the commented-out lines were separated by spaces (I assume these were failed attempts).
excludepkgs=wine*,resolvconf,systemd-resolved
Did work. I missed what Samuel's said.
This is a regression from Fedora 36. I updates the bug report.
It might be a change, but it's not a regression. It's clearly documented in the man page.
Where in the man page does it say you can only have one entry, so cram it all on the same line?
On 4 Feb 2023, at 08:33, ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2/4/23 00:05, Samuel Sieb wrote:
On 2/3/23 21:32, ToddAndMargo via users wrote: On 2/3/23 20:10, Go Canes wrote:
On Fri, Feb 3, 2023 at 10:11 PM Todd Zullinger tmz@pobox.com wrote:
This is not the way I've ever seen excludepkgs used or documented. The man page states:
excludepkgs list Exclude packages of this repository, speci‐ fied by a name or a glob and separated by a comma, from all operations. Can be disabled using --disableexcludes command line switch. Defaults to [].
Put them all together, not a bunch of different definitions.
Note: "separated by a comma" - the commented-out lines were separated by spaces (I assume these were failed attempts).
excludepkgs=wine*,resolvconf,systemd-resolved
Did work. I missed what Samuel's said.
This is a regression from Fedora 36. I updates the bug report.
It might be a change, but it's not a regression. It's clearly documented in the man page.
Where in the man page does it say you can only have one entry, so cram it all on the same line?
Where does it say you can repeat lines?
I always understood that each tag can only appear once.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 2/4/23 00:39, Barry wrote:
On 4 Feb 2023, at 08:33, ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2/4/23 00:05, Samuel Sieb wrote:
On 2/3/23 21:32, ToddAndMargo via users wrote: On 2/3/23 20:10, Go Canes wrote:
On Fri, Feb 3, 2023 at 10:11 PM Todd Zullinger tmz@pobox.com wrote:
This is not the way I've ever seen excludepkgs used or documented. The man page states:
excludepkgs list Exclude packages of this repository, speci‐ fied by a name or a glob and separated by a comma, from all operations. Can be disabled using --disableexcludes command line switch. Defaults to [].
Put them all together, not a bunch of different definitions.
Note: "separated by a comma" - the commented-out lines were separated by spaces (I assume these were failed attempts).
excludepkgs=wine*,resolvconf,systemd-resolved
Did work. I missed what Samuel's said.
This is a regression from Fedora 36. I updates the bug report.
It might be a change, but it's not a regression. It's clearly documented in the man page.
Where in the man page does it say you can only have one entry, so cram it all on the same line?
Where does it say you can repeat lines?
I always understood that each tag can only appear once.
Seems I got away with it a lot
ToddAndMargo via users wrote:
On 2/4/23 00:39, Barry wrote:
I always understood that each tag can only appear once.
Seems I got away with it a lot
Multiple excludepkgs entries in dnf.conf don't work in f36 either. Only the last one is used.
# rpm -q dnf dnf-4.14.0-1.fc36.noarch # printf 'excludepkgs=%s\n' 'wine*' 'git*' >>/etc/dnf/dnf.conf # dnf -qq list wine | cat Available Packages wine.i686 8.0-1.fc36 updates wine.x86_64 8.0-1.fc36 updates # sed -i '/^excludepkgs=/d' /etc/dnf/dnf.conf # printf 'excludepkgs=%s\n' 'git*' 'wine*' >>/etc/dnf/dnf.conf # dnf -qq list wine Error: No matching Packages to list # dnf -qq list git | cat Available Packages git.x86_64 2.39.1-1.fc36 updates
I'm not sure you got away with anything. You may not have noticed it wasn't working as you had hoped. :)
On 2/4/23 08:59, Todd Zullinger wrote:
ToddAndMargo via users wrote:
On 2/4/23 00:39, Barry wrote:
I always understood that each tag can only appear once.
Seems I got away with it a lot
Multiple excludepkgs entries in dnf.conf don't work in f36 either. Only the last one is used.
# rpm -q dnf dnf-4.14.0-1.fc36.noarch # printf 'excludepkgs=%s\n' 'wine*' 'git*' >>/etc/dnf/dnf.conf # dnf -qq list wine | cat Available Packages wine.i686 8.0-1.fc36 updates wine.x86_64 8.0-1.fc36 updates # sed -i '/^excludepkgs=/d' /etc/dnf/dnf.conf # printf 'excludepkgs=%s\n' 'git*' 'wine*' >>/etc/dnf/dnf.conf # dnf -qq list wine Error: No matching Packages to list # dnf -qq list git | cat Available Packages git.x86_64 2.39.1-1.fc36 updates
I'm not sure you got away with anything. You may not have noticed it wasn't working as you had hoped. :)
Oh I would have noticed instantly. Wine 7 was a total DISASTER and did a number on my business!
I wonder if it was a dnf update I had yet to install. Hmmmmm...
ToddAndMargo via users wrote:
On 2/4/23 08:59, Todd Zullinger wrote:
I'm not sure you got away with anything. You may not have noticed it wasn't working as you had hoped. :)
Oh I would have noticed instantly.
[...]
I wonder if it was a dnf update I had yet to install. Hmmmmm...
The last dnf update in f36 was 5 months ago. The one before that was 9 months ago. It's unlikely.
On Feb 5, 2023, at 18:38, Todd Zullinger tmz@pobox.com wrote:
ToddAndMargo via users wrote:
On 2/4/23 08:59, Todd Zullinger wrote: I'm not sure you got away with anything. You may not have noticed it wasn't working as you had hoped. :)
Oh I would have noticed instantly.
[...]
I wonder if it was a dnf update I had yet to install. Hmmmmm...
The last dnf update in f36 was 5 months ago. The one before that was 9 months ago.
I poked around the source for dnf on GitHub, and I do see a commit from 2021 which kinda backs up the multiple lines argument:
https://github.com/rpm-software-management/dnf/pull/1779
However, best I understand it was so you could append excludes in a *repo* file, not multiple appending lines in the main dnf.conf.
Trying to read the code on my phone is giving me a headache so I will leave it up to smarter people here.
-- Jonathan Billings
On 2/4/23 08:59, Todd Zullinger wrote:
Multiple excludepkgs entries in dnf.conf don't work in f36 either. Only the last one is used.
I wonder if they are reading in dnf.conf file with a bash script.
# Source network variables . /etc/sysconfig/network
Would certainly over write all but the last one.
And if so, my memory of it working in FC36 must be really bad. On the other hand if dnf had upgraded wine to 7 on me, I would have know instantly and had been furious.
When I write programs (Raku), I read the whole thing in and parse through what I want. If I did not realize that their were multiple instances, then on the first one would be be the only one read.
But, then again, I print out the .conf file in another shell and examine what is in it before starting coding
On Sat, Feb 4, 2023 at 3:33 AM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2/4/23 00:05, Samuel Sieb wrote:
On 2/3/23 21:32, ToddAndMargo via users wrote:
On 2/3/23 20:10, Go Canes wrote:
On Fri, Feb 3, 2023 at 10:11 PM Todd Zullinger tmz@pobox.com wrote:
This is not the way I've ever seen excludepkgs used or documented. The man page states:
excludepkgs list Exclude packages of this repository, speci‐ fied by a name or a glob and separated by a comma, from all operations. Can be disabled using --disableexcludes command line switch. Defaults to [].
Put them all together, not a bunch of different definitions.
Note: "separated by a comma" - the commented-out lines were separated by spaces (I assume these were failed attempts).
excludepkgs=wine*,resolvconf,systemd-resolved
Did work. I missed what Samuel's said.
This is a regression from Fedora 36. I updates the bug report.
It might be a change, but it's not a regression. It's clearly documented in the man page.
Where in the man page does it say you can only have one entry, so cram it all on the same line?
I don't see the discussion in the dnf(8) man page after a quick read. And in particular, the discussion under PACKAGE FILTERING.[1]
I think the use of multiple excludepkgs is intuitive. Each time you want to pin a package, you add an excludepkgs. When you no longer want to pin a package, you delete the particular excludepkgs. I also understand the usage may be one excludepkgs with commas separating a list of package names. That makes sense, too.
I think this is probably a documentation bug. You should file a bug report at https://bugzilla.redhat.com/ .
Jeff
On Sat, 2023-02-04 at 13:55 -0500, Jeffrey Walton wrote:
I think the use of multiple excludepkgs is intuitive. Each time you want to pin a package, you add an excludepkgs.
I don't. It flies in the face of many other configuration files that I've adjusted. If I do something like the following in one file:
setting=this setting=that setting=something
The setting gets changed on each iteration, and finally becomes just:
setting=something
Sure, there are *some* exceptions, but *there* the documentation tells that multiple statements can be used. e.g. Various servers let you do:
listen 127.0.0.1:80 listen 192.168.0.1:8080
So it'll listen on more than one interface and port.
Trying to be logical about it you might want to pick on the absence or presence of the equals sign, but I highly doubt that's consistent behaviour.
Sure it could be somewhat of a documentation problem, that it says nothing about this, though I'm never inclined to do things that docs don't suggest are possible. Certainly not without some experimenting, and always being mindful that undocumented features can never be relied upon, now or later on.
Back in the days of when we had no compilers and had to program the CPU directly in op-codes, there were a few undocumented commands that were nick-named HCF codes (for Halt and Catch Fire). They worked on some CPUs and not others.
On Sat, Feb 4, 2023 at 11:33 PM Tim ignored_mailbox@yahoo.com.au wrote:
On Sat, 2023-02-04 at 13:55 -0500, Jeffrey Walton wrote:
I think the use of multiple excludepkgs is intuitive. Each time you want to pin a package, you add an excludepkgs.
I don't. It flies in the face of many other configuration files that I've adjusted. If I do something like the following in one file:
I hope multiple configuration files in config.d/ directories don't offend your delicate sensibilities.
Jeff
On Sun, 5 Feb 2023 00:42:28 -0500 Jeffrey Walton noloader@gmail.com wrote:
On Sat, Feb 4, 2023 at 11:33 PM Tim ignored_mailbox@yahoo.com.au wrote:
On Sat, 2023-02-04 at 13:55 -0500, Jeffrey Walton wrote:
I think the use of multiple excludepkgs is intuitive. Each time you want to pin a package, you add an excludepkgs.
I don't. It flies in the face of many other configuration files that I've adjusted. If I do something like the following in one file:
I hope multiple configuration files in config.d/ directories don't offend your delicate sensibilities.
That isn't the same thing. Config.d directories are designated as places where multiple configuration files are placed. Tim is talking about historical convention for a single configuration file.
And the way you phrased your response comes across as sarcastic and demeaning, almost as a personal attack. Maybe you didn't mean it that way, but that's how I would interpret it. You could have said something like, "What about multiple configuration files in config.d directories? Doesn't that contradict what you are saying?"
On Sun, Feb 5, 2023 at 11:08 AM stan upaitag@zoho.com wrote:
On Sun, 5 Feb 2023 00:42:28 -0500 Jeffrey Walton noloader@gmail.com wrote:
On Sat, Feb 4, 2023 at 11:33 PM Tim ignored_mailbox@yahoo.com.au wrote:
On Sat, 2023-02-04 at 13:55 -0500, Jeffrey Walton wrote:
I think the use of multiple excludepkgs is intuitive. Each time you want to pin a package, you add an excludepkgs.
I don't. It flies in the face of many other configuration files that I've adjusted. If I do something like the following in one file:
I hope multiple configuration files in config.d/ directories don't offend your delicate sensibilities.
That isn't the same thing. Config.d directories are designated as places where multiple configuration files are placed. Tim is talking about historical convention for a single configuration file.
And the way you phrased your response comes across as sarcastic and demeaning, almost as a personal attack. Maybe you didn't mean it that way, but that's how I would interpret it. You could have said something like, "What about multiple configuration files in config.d directories? Doesn't that contradict what you are saying?"
No, I did.
I don't feel like engaging in another endless debate the same folks seem to engage in on this list.
The thrust of my post was the documentation bug, not his personal opinion of me being incorrect.
Jeff
On Sun, 2023-02-05 at 09:08 -0700, stan via users wrote:
And the way you phrased your response comes across as sarcastic and demeaning, almost as a personal attack. Maybe you didn't mean it that way, but that's how I would interpret it.
That's how I took it.
I gave a reasoned response about why I didn't think it was "intuitive" and got a rude hissy fit in response.
I don't *expect* that setting the same variable several times over would anything other than re-set it each time, that's actually *contrary* to what I'd *expect*.
Sure, that is an "opinion," but not an unreasonable one, nor a rude one, nor different from historical experience of how variables are set in programs. Hence how I came to that conclusion. Thus far I've not seen a configuration file where I could set a variable to different things, and have them all accumulate. It's counter to my experience.
Just off the top of my head, out of the services I've made use of over the years, I wouldn't expect it work in BIND, DHCP, Apache, sendmail, postfix, Dovecot, NTPD, CUPS, Samba, yum, dnf. Nor any of the programming languages I've used since the 1980s. Sure, a person's experience is only ever going to be a subset of *everything*, but it gives you a fair idea of what to expect when configuring things.
I only *expect* one of two things to happen:
1. The last time the variable is set, is what it will be. 2. The program to error-out and complain that a variable has been set twice.
Yes, it *could* work *otherwise*, but the man file doesn't suggest so, I'd be surprised if it did, and *I* wouldn't rely on undocumented features or quirks. I pointed out the historical aspect of doing things like that (using undocumented features), they became know as "HCF codes."
I also pointed out the clue in the configuration file that would lead me to *expect* that kind of behaviour:
variable-name = adjustable-values
The equal sign implies this is that, it doesn't imply anything else.
The really odd thing is they want to argue strongly against the case of what it appears to do (work how I expected it to) for a behaviour that would be programmatically peculiar, that the manual doesn't even slightly suggest, but does quite clearly explain how you're expected to use it.
Why would you expect it to work in some way that's different from the instructions?
On 2/6/23 04:52, Tim via users wrote:
The really odd thing is they want to argue strongly against the case of what it appears to do (work how I expected it to) for a behaviour that would be programmatically peculiar, that the manual doesn't even slightly suggest, but does quite clearly explain how you're expected to use it.
Why would you expect it to work in some way that's different from the instructions?
Hi Tim,
If dnf is using bash "source", each instance of the variable would erase the previous.
I also saw nowhere in the instructions (man page) to only use them once. I could have missed it.
And if you look at the now closed bug report, the annalist went all the way back to FC26 and found the behavior consistent with the last instance model.
So, although I still am scratching my head as to why I ever go it to work and what I though I was really seeing, I am clearly the one at fault.
-T
On 2/6/23 13:39, ToddAndMargo via users wrote:
I also saw nowhere in the instructions (man page) to only use them once. I could have missed it.
Because that's the normal way config files work. If you can have the same option multiple times, that's a rare exception and would be documented as such.
On Mon, 2023-02-06 at 13:39 -0800, ToddAndMargo via users wrote:
So, although I still am scratching my head as to why I ever go it to work and what I though I was really seeing, I am clearly the one at fault.
My only guess could be, that at the time you added a line, that issue was the thing that concerned you at the time.
On 2/6/23 17:50, Tim via users wrote:
On Mon, 2023-02-06 at 13:39 -0800, ToddAndMargo via users wrote:
So, although I still am scratching my head as to why I ever go it to work and what I though I was really seeing, I am clearly the one at fault.
My only guess could be, that at the time you added a line, that issue was the thing that concerned you at the time.
And it was at the bottom of the file at the time.
That all makes sense.