Dne 14. 03. 22 v 23:23 John Reiser napsal(a):
The default /etc/dnf/dnf.conf lists only a few options
with no individual documentation, and contains no explicit pointer
to more documentation. I expect better: all reasonable attempts
should lead quickly to the relevant documentation. This is the
On 3/14/22 15:23, John Reiser wrote:
On 3/14/22 12:23, Samuel Sieb wrote:
On 3/14/22 09:34, John Reiser wrote:
Just setting `deltarpm` to False in dnf.conf do the same. Just saying.
The deltarpm option has low discoverability. The information is
available,
but the discovery chain is too
On 3/14/22 12:23, Samuel Sieb wrote:
On 3/14/22 09:34, John Reiser wrote:
Just setting `deltarpm` to False in dnf.conf do the same. Just saying.
The deltarpm option has low discoverability. The information is available,
but the discovery chain is too long and not explicit enough.
The main
On 3/14/22 09:34, John Reiser wrote:
Just setting `deltarpm` to False in dnf.conf do the same. Just saying.
The deltarpm option has low discoverability. The information is available,
but the discovery chain is too long and not explicit enough.
The main configuration file /etc/dnf/dnf.conf
Just setting `deltarpm` to False in dnf.conf do the same. Just saying.
The deltarpm option has low discoverability. The information is available,
but the discovery chain is too long and not explicit enough.
The main configuration file /etc/dnf/dnf.conf does not list
each option, its default
Dne 07. 03. 22 v 6:29 Gary Buhrmaster napsal(a):
One of the first things I did on a new install was remove
deltarpm, and add it to the global exclude list so it would
not get installed on a system/package upgrade. It was a
pure win for my systems. Obviously your experience will
vary.
Why so
On Mon, Mar 7, 2022 at 5:03 AM Gordon Messmer wrote:
> I remember in the early days of deltarpm, it would frequently reduce the
> download size on my systems by 70-90%. I know that some people disliked
> that it made updates slower, but I always thought that reducing the
> bandwidth costs at
On 3/6/22 10:29, Nico Kadel-Garcia wrote:
I have always disliked deltarpms. They expand the size of the
frequently downloaded metadata with little overall benefit.
Wasn't Jonathan's point that the benefit is "little" because of
infrastructure issues?
I remember in the early days of
On 3/6/22 18:10, John Reiser wrote:
>
>> I have also strongly disliked deltarpms. They very rarely help and
>> significantly increase attack surface.
> If deltarpm succeeds and both the old .rpm and the new.rpm are signed,
> then how is the attack surface larger, as long as any consumer
>
On 3/6/22 13:39, Demi Marie Obenour wrote:
I have also strongly disliked deltarpms. They very rarely help and
significantly increase attack surface.
If deltarpm succeeds and both the old .rpm and the new.rpm are signed,
then how is the attack surface larger, as long as any consumer
verifies
On 3/6/22 13:29, Nico Kadel-Garcia wrote:
> On Sun, Mar 6, 2022 at 8:51 AM Jonathan Dieter wrote:
>>
>> Hi everyone,
>>
>> I'm orphaning deltarpm because, as it's currently used in Fedora, it's
>> not very effective, bugs keep getting opened against it be
On Sun, Mar 6, 2022 at 8:51 AM Jonathan Dieter wrote:
>
> Hi everyone,
>
> I'm orphaning deltarpm because, as it's currently used in Fedora, it's
> not very effective, bugs keep getting opened against it because it's
> not working as well as it should (mostly an infr
Hi everyone,
I'm orphaning deltarpm because, as it's currently used in Fedora, it's
not very effective, bugs keep getting opened against it because it's
not working as well as it should (mostly an infra issue as opposed to a
problem with the tool itself), and I no longer have the time
13 matches
Mail list logo
