On Tue, Jan 05, 2021 at 07:01:56PM +, Matthew Almond via devel wrote:
> Signature *verification* partially works. Everything to do with
> signatures on just the header works (and the header describes the
> payload digest). There is one specific area which needs fixed: regular
> RPMs are read,
On Mon, 2020-12-21 at 11:28 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RPMCoW
>
>
> == Summary ==
>
> RPM Copy on Write provides a better experience for Fedora Users as it
> reduces the amount of I/O and offsets CPU cost of package
> decompression. RPM Copy on Write uses
On Tue, 2021-01-05 at 18:18 +0100, Daniel Mach wrote:
> Dne 24. 12. 20 v 22:54 Matthew Almond via devel napsal(a):
> > Depends on how it got there, and what you asked for. Here's some
> > examples:
> >
> > 1. cp foo.rpm /var/cache/dnf//Packages/ && dnf install foo
> > ...will fail the librepo
Dne 24. 12. 20 v 22:54 Matthew Almond via devel napsal(a):
Depends on how it got there, and what you asked for. Here's some
examples:
1. cp foo.rpm /var/cache/dnf//Packages/ && dnf install foo
...will fail the librepo full file check, and it'll be re-
downloaded.
2. dnf install
On Sun, 2021-01-03 at 16:16 -0500, Colin Walters wrote:
>
> On Sat, Jan 2, 2021, at 10:03 AM, Zbigniew Jędrzejewski-Szmek wrote:
>
> > I fail to see why this would be significantly better...
>
> I don't claim that the "separate temporary directory of unpacked
> content" is *better* - just that
On Sun, Jan 03, 2021 at 03:25:29PM -0800, Kevin Fenzi wrote:
> I remember when drpms landed I heard people say they choose Fedora
> because of them. That may have changed over the years I guess. :)
> and there have been only 2 or 3 reports about how few drpms exist
> in the last few years (ie,
On Sat, Jan 02, 2021 at 06:17:03PM +, Jonathan Dieter wrote:
> On Sat, 2021-01-02 at 18:12 +, Jonathan Dieter wrote:
> > FWIW, I also think it's time for drpms to go. Aside from any potential
> > issues with the proposed change, they haven't been useful in Fedora for
> > three years, (see
On Sat, Jan 2, 2021, at 10:03 AM, Zbigniew Jędrzejewski-Szmek wrote:
> I fail to see why this would be significantly better...
I don't claim that the "separate temporary directory of unpacked content" is
*better* - just that it's as easy to implement *and* doesn't require an RPM
format
On Sat, 2021-01-02 at 18:12 +, Jonathan Dieter wrote:
> FWIW, I also think it's time for drpms to go. Aside from any potential
> issues with the proposed change, they haven't been useful in Fedora for
> three years, (see https://pagure.io/releng/issue/7215), and nobody's
> been able to put in
On Sat, 2021-01-02 at 13:42 +, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Dec 30, 2020 at 10:10:27AM -0800, Kevin Fenzi wrote:
>
> This is most likely because we are only making drpms against the most
> recent updates. So, we are making very few drpms and only against
> things
> that recently
On Tue, Dec 22, 2020 at 09:41:35PM -, Matthew Almond via devel wrote:
> > On Mon, Dec 21, 2020, at 1:07 PM, Neal Gompa wrote:
> >
> > Yes it does. It avoids writing the compressed data and then copying it
> > back out
> > uncompressed, which is the same amount of savings as the reflink
On Wed, Dec 30, 2020 at 10:10:27AM -0800, Kevin Fenzi wrote:
> On Wed, Dec 30, 2020 at 01:18:38PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Dec 22, 2020 at 05:09:08PM -0500, Matthew Miller wrote:
> > > On Tue, Dec 22, 2020 at 02:02:13PM -0800, Kevin Fenzi wrote:
> > > > > delta rpms
On Wed, Dec 30, 2020 at 01:18:38PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Dec 22, 2020 at 05:09:08PM -0500, Matthew Miller wrote:
> > On Tue, Dec 22, 2020 at 02:02:13PM -0800, Kevin Fenzi wrote:
> > > > delta rpms safe so much time in form of bandwidth on the client side.
> > > Well,
On Tue, Dec 22, 2020 at 05:09:08PM -0500, Matthew Miller wrote:
> On Tue, Dec 22, 2020 at 02:02:13PM -0800, Kevin Fenzi wrote:
> > > delta rpms safe so much time in form of bandwidth on the client side.
> > Well, it's tradeoffs. They save bandwith and download time on one side,
> > but use lots of
On Wed, 2020-12-23 at 19:23 -0500, James Cassell wrote:
> # Resolve packaging request into a list of packages and operations
> > # Download and '''decompress''' packages into a '''locally
> > optimized''' rpm file
>
> Please verify the signature on the downloaded RPM before
> decompressing it.
On Mon, Dec 21, 2020, at 11:28 AM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RPMCoW
>
>
> == Summary ==
>
> RPM Copy on Write provides a better experience for Fedora Users as it
> reduces the amount of I/O and offsets CPU cost of package
> decompression. RPM Copy on Write uses
On Mon, Dec 21, 2020 at 10:49 AM Colin Walters wrote:
>
>
>
> On Mon, Dec 21, 2020, at 11:28 AM, Ben Cotton wrote:
> > ## Regular RPMs use a compressed .cpio based payload. In contrast,
> > extent based RPMs contain uncompressed data aligned to the fundamental
> > page size of the architecture,
On Tuesday, December 22, 2020 4:54:34 PM EST Matthew Almond via devel wrote:
> > I currently download once and upgrade three different systems by
> > rsync-ing the cache.
> >
> > Do I understand that this will no longer be supported or work?
>
> That's an interesting question. Is sharing the cache
On Tue, Dec 22, 2020 at 02:02:13PM -0800, Kevin Fenzi wrote:
> > delta rpms safe so much time in form of bandwidth on the client side.
> Well, it's tradeoffs. They save bandwith and download time on one side,
> but use lots of cpu cycles and disk space on the other. It just depends
> on what each
On Mon, Dec 21, 2020 at 07:14:08PM +0100, Marius Schwarz wrote:
> Am 21.12.20 um 18:53 schrieb Kevin Fenzi:
> > But in general perhaps we should decide how much value drpms provide
> > these days and either make sure we are making more of them, or drop
> > them.
> delta rpms safe so much time in
> I currently download once and upgrade three different systems by
> rsync-ing the cache.
>
> Do I understand that this will no longer be supported or work?
That's an interesting question. Is sharing the cache directory from a single
host intended to be shared like this? I am guessing no, but
> On Mon, Dec 21, 2020, at 1:07 PM, Neal Gompa wrote:
>
> Yes it does. It avoids writing the compressed data and then copying it back
> out
> uncompressed, which is the same amount of savings as the reflink approach.
>
> (It's also equally incompatible with deltarpm)
>
>
> No - static deltas
On Tue, Dec 22, 2020 at 12:58 PM Matthew Almond via devel
wrote:
>
> There is also some confusion between compressed data in the rpm and the
> transcoded one, and filesystem level compression. This proposal affects the
> former, but not the latter. I'd caution against using btrfs specific
>
>> === New process ===
>> # Resolve packaging request into a list of packages and operations
>> # Download and '''decompress''' packages into a '''locally optimized''' rpm
>> file
>> # Install and/or upgrade packages sequentially using RPM files, using
>> ''reference linking''' (reflinking) to
> I cannot find it anywhere in rpm codebase.
The current status section of the proposal describes this as pending two PRs,
and in the dependencies list, they're enumerated. Most of the code is in
https://github.com/malmond77/rpm/tree/cow and enabled through work in
Dne 21. 12. 20 v 17:39 Neal Gompa napsal(a):
> On Mon, Dec 21, 2020 at 11:29 AM Ben Cotton wrote:
>> # Decompression happens inline with download. This has a positive
>> effect on resource usage: downloads are typically limited by
>> bandwidth. Decompression and writing the full data into a
On Mon, Dec 21, 2020, 8:19 PM Davide Cavalca via devel <
devel@lists.fedoraproject.org> wrote:
> On Mon, 2020-12-21 at 12:54 -0400, Robert Marcano via devel wrote:
> > On 12/21/20 12:28 PM, Ben Cotton wrote:
> > > ...
> > >
> > > === New process ===
> > >
> > > # Resolve packaging request into a
Neal Gompa writes:
On Mon, Dec 21, 2020 at 1:14 PM Marius Schwarz
wrote:
>
> If something really needs to change, it is the 50+ MB repo database that
> gets downloaded. It takes ages on slow connections to download
> and than you want to increase the size of the rpms too.. Doesn't sound
>
On Mon, 2020-12-21 at 12:48 -0500, Colin Walters wrote:
>
> On Mon, Dec 21, 2020, at 11:28 AM, Ben Cotton wrote:
> >
> >
> > == Summary ==
> >
> > RPM Copy on Write provides a better experience for Fedora Users as
> > it
> > reduces the amount of I/O and offsets CPU cost of package
> >
On Mon, 2020-12-21 at 12:54 -0400, Robert Marcano via devel wrote:
> On 12/21/20 12:28 PM, Ben Cotton wrote:
> > ...
> >
> > === New process ===
> >
> > # Resolve packaging request into a list of packages and operations
> > # Download and '''decompress''' packages into a '''locally
> >
On Mon, 2020-12-21 at 09:53 -0800, Kevin Fenzi wrote:
> Cool. A few questions inline...
>
> On Mon, Dec 21, 2020 at 11:28:51AM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/RPMCoW
> >
> >
> > == Summary ==
> >
> > RPM Copy on Write provides a better experience for Fedora
On Mon, Dec 21, 2020 at 2:14 PM Matthew Miller wrote:
>
> On Mon, Dec 21, 2020 at 01:47:19PM -0500, Neal Gompa wrote:
> > As someone who has to package for multiple distributions, I would
> > oppose any attempt to cripple DNF to stop supporting file dependencies
> > properly. I *aggressively* use
On Mon, Dec 21, 2020 at 01:47:19PM -0500, Neal Gompa wrote:
> As someone who has to package for multiple distributions, I would
> oppose any attempt to cripple DNF to stop supporting file dependencies
> properly. I *aggressively* use file dependencies to avoid having to
> litter my spec files with
On Mon, Dec 21, 2020 at 1:42 PM Matthew Miller wrote:
>
> On Mon, Dec 21, 2020 at 07:14:08PM +0100, Marius Schwarz wrote:
> > delta rpms safe so much time in form of bandwidth on the client side.
> > If something really needs to change, it is the 50+ MB repo database
> > that gets downloaded. It
On Monday, December 21, 2020 11:28:51 AM EST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RPMCoW
[snip]
> # The file format for RPMs is different with Copy on Write. The
> headers are identical, but the payload is different. There is also a
> footer.
> ## Files are converted
On Mon, Dec 21, 2020, at 1:07 PM, Neal Gompa wrote:
>
> Sure, this makes some degree of sense, but it doesn't reduce the IOPS
> for actually *doing* the installation.
Yes it does. It avoids writing the compressed data and then copying it back
out uncompressed, which is the same amount of
On Mon, Dec 21, 2020 at 07:14:08PM +0100, Marius Schwarz wrote:
> delta rpms safe so much time in form of bandwidth on the client side.
> If something really needs to change, it is the 50+ MB repo database
> that gets downloaded. It takes ages on slow connections to download
This needs a
On Mon, Dec 21, 2020 at 1:14 PM Marius Schwarz wrote:
>
> Am 21.12.20 um 18:53 schrieb Kevin Fenzi:
> > But in general perhaps we should decide how much value drpms provide
> > these days and either make sure we are making more of them, or drop
> > them.
> delta rpms safe so much time in form of
On Mon, Dec 21, 2020 at 01:07:42PM -0500, Neal Gompa wrote:
> As an aside, I *really* hate this split of terminology we have among
> Editions, Spins, and Labs. It's confusing to everyone. :(
The website hasn't been changed, but officially all of these are Fedora
Solutions, with only Editions
Am 21.12.20 um 18:53 schrieb Kevin Fenzi:
But in general perhaps we should decide how much value drpms provide
these days and either make sure we are making more of them, or drop
them.
delta rpms safe so much time in form of bandwidth on the client side.
If something really needs to change, it
On Mon, Dec 21, 2020 at 12:49 PM Colin Walters wrote:
>
>
>
> On Mon, Dec 21, 2020, at 11:28 AM, Ben Cotton wrote:
> >
> >
> >
> > == Summary ==
> >
> > RPM Copy on Write provides a better experience for Fedora Users as it
> > reduces the amount of I/O and offsets CPU cost of package
> >
On Mon, 2020-12-21 at 18:00 +0100, Tomasz Torcz wrote:
> On Mon, Dec 21, 2020 at 11:28:51AM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/RPMCoW
> > # dnf-plugin-reflink (a new package):
> > https://github.com/facebookincubator/dnf-plugin-cow/
>
> Does not exists, but
Cool. A few questions inline...
On Mon, Dec 21, 2020 at 11:28:51AM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RPMCoW
>
>
> == Summary ==
>
> RPM Copy on Write provides a better experience for Fedora Users as it
> reduces the amount of I/O and offsets CPU cost of package
On Mon, Dec 21, 2020, at 11:28 AM, Ben Cotton wrote:
>
>
>
> == Summary ==
>
> RPM Copy on Write provides a better experience for Fedora Users as it
> reduces the amount of I/O and offsets CPU cost of package
> decompression. RPM Copy on Write uses reflinking capabilities in
> btrfs, which
On Mon, Dec 21, 2020 at 11:58 AM Michael Catanzaro wrote:
>
>
> On Mon, Dec 21, 2020 at 11:39 am, Neal Gompa wrote:
> > This is very exciting! There is one thing, though: we need a libdnf
> > plugin for PackageKit to use too. "DNF plugins" are at the Python
> > layer, and libdnf has its own
On Mon, Dec 21, 2020 at 11:28:51AM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RPMCoW
> # dnf-plugin-reflink (a new package):
> https://github.com/facebookincubator/dnf-plugin-cow/
Does not exists, but I've just noticed it mentioned in Current Status
on Wiki:
3.2 Github
On Mon, Dec 21, 2020 at 11:39 am, Neal Gompa wrote:
This is very exciting! There is one thing, though: we need a libdnf
plugin for PackageKit to use too. "DNF plugins" are at the Python
layer, and libdnf has its own plugin system that C/C++ consumers can
use. So if both a libdnf and a dnf
On 12/21/20 12:28 PM, Ben Cotton wrote:
...
=== New process ===
# Resolve packaging request into a list of packages and operations
# Download and '''decompress''' packages into a '''locally optimized''' rpm file
# Install and/or upgrade packages sequentially using RPM files, using
'''reference
On Mon, Dec 21, 2020 at 11:29 AM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/RPMCoW
>
>
> == Summary ==
>
> RPM Copy on Write provides a better experience for Fedora Users as it
> reduces the amount of I/O and offsets CPU cost of package
> decompression. RPM Copy on Write uses
https://fedoraproject.org/wiki/Changes/RPMCoW
== Summary ==
RPM Copy on Write provides a better experience for Fedora Users as it
reduces the amount of I/O and offsets CPU cost of package
decompression. RPM Copy on Write uses reflinking capabilities in
btrfs, which is the default filesystem in
50 matches
Mail list logo
