On Wed, Jul 2, 2014 at 6:04 PM, Reindl Harald h.rei...@thelounge.net wrote:
but it's just dangerous to assume that will be forever true
Agreed with this, but:
and as you can see below with gzip you have *always*
different results for the same data
This is not true, see below.
Doesn't the current process assume that xz always produces the same
output?
What would happen if a newer version of xz/lzma comes out which (for
example) produces better compressed output while still remaining
compatible with the file format and older decompression tools?
Rich.
--
Richard
This has already happened once before a few years back. IIRC, we
updated xz on the builder to match the one in Fedora, but our users had
broken deltarpms until they got the updated xz.
Jonathan
On 07/02/2014 07:46 AM, Richard W.M. Jones wrote:
Doesn't the current process assume that xz
Am 02.07.2014 16:46, schrieb Richard W.M. Jones:
Doesn't the current process assume that xz always
produces the same output?
hopefully not
What would happen if a newer version of xz/lzma comes out which (for
example) produces better compressed output while still remaining
compatible with
Doesn't the current process assume that xz always produces the same
output?
Yes, the deltarpm process depends on xz giving the same output
when run by the consumer of the .drpm as when run by the producer.
If not, then deltarpm gives a warning and ignores the .drpm --
the entire new .rpm must
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 27 Jun 2014 11:35:20 -0600
Kevin Fenzi ke...@scrye.com wrote:
On Fri, 27 Jun 2014 19:23:04 +0200
drago01 drag...@gmail.com wrote:
Why?
My understanding of the process as it exists:
Download drpm.
Take drpm contents + old
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 29 Jun 2014 20:01:04 -0500
Jon jdisn...@gmail.com wrote:
On Sun, Jun 29, 2014 at 7:42 PM, Stephen John Smoogen
smo...@gmail.com wrote:
[snip]
Personally I would just say don't make delta-rpms for i386 and arm
or just have
On Mon, Jun 30, 2014 at 3:01 AM, Jon jdisn...@gmail.com wrote:
On Sun, Jun 29, 2014 at 7:42 PM, Stephen John Smoogen smo...@gmail.com
wrote:
[snip]
Personally I would just say don't make delta-rpms for i386 and arm or just
have deltarpm=1 on those architectures by default.
Or all
Rahul Sundaram metherid at gmail.com writes:
All that being said, what is the criteria for getting a default
configuration line put into yum.conf?
I'd really like to get the deltarpm= line put in there.
File a bug report in yum bug tracker or Red Hat bugzilla against yum as
the component.
On Sun, Jun 29, 2014 at 1:55 AM, Jonathan Dieter jdie...@lesbg.com wrote:
2. RPM would also need to support signatures across the uncompressed payload
as well as the compressed payload.
Well Florian said that only the header is actually signed not the
payload. So this shouldn't be necessary.
On Sun, Jun 29, 2014 at 12:09 PM, Andre Robatino
robat...@fedoraproject.org wrote:
Rahul Sundaram metherid at gmail.com writes:
All that being said, what is the criteria for getting a default
configuration line put into yum.conf?
I'd really like to get the deltarpm= line put in there.
File
drago01 drago01 at gmail.com writes:
Well they should (or have some other source of documentation) ... the
config file isn't really the right place for documentation, given
that it does not get updated once you have edited it once ... you will
miss new options / changed semantics that way.
On 06/29/2014 12:34 PM, drago01 wrote:
Well they should (or have some other source of documentation) ... the
config file isn't really the right place for documentation, given
that it does not get updated once you have edited it once ... you will
miss new options / changed semantics that way.
On 06/29/2014 12:32 PM, drago01 wrote:
On Sun, Jun 29, 2014 at 1:55 AM, Jonathan Dieter jdie...@lesbg.com wrote:
2. RPM would also need to support signatures across the uncompressed payload
as well as the compressed payload.
Well Florian said that only the header is actually signed not the
On 06/29/2014 04:36 AM, Florian Weimer wrote:
On 06/29/2014 12:32 PM, drago01 wrote:
On Sun, Jun 29, 2014 at 1:55 AM, Jonathan Dieter jdie...@lesbg.com
wrote:
2. RPM would also need to support signatures across the uncompressed
payload
as well as the compressed payload.
Well Florian said
On Sun, 29 Jun 2014 14:20:44 -0700
Jonathan Dieter jdie...@lesbg.com wrote:
We can do this, but createrepo would need to store the checksum of 0
level compressed xz rpms in primary, which involve making createrepo
decompress each rpm and then recompress at level 0. Not sure what
the infra
On 29 June 2014 15:34, Kevin Fenzi ke...@scrye.com wrote:
On Sun, 29 Jun 2014 14:20:44 -0700
Jonathan Dieter jdie...@lesbg.com wrote:
We can do this, but createrepo would need to store the checksum of 0
level compressed xz rpms in primary, which involve making createrepo
decompress each
On 06/27/2014 07:13 PM, Kevin Fenzi wrote:
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 drag...@gmail.com wrote:
That wasn't about poor as in slow vs. great as in fast but
bandwith capped vs. not.
If building deltas are slow the solution is not to disable them but to
find out why there are slow
On Sat, Jun 28, 2014 at 12:22 PM, Florian Weimer fwei...@redhat.com wrote:
On 06/27/2014 07:13 PM, Kevin Fenzi wrote:
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 drag...@gmail.com wrote:
That wasn't about poor as in slow vs. great as in fast but
bandwith capped vs. not.
If building deltas
On Sat, 28 Jun 2014 12:51:07 +0200
drago01 drag...@gmail.com wrote:
On Sat, Jun 28, 2014 at 12:22 PM, Florian Weimer fwei...@redhat.com
...snip...
The signature is on the RPM header, not the payload. The RPM
header only lists digests of individual files (after decompression).
So this
On Sat, Jun 28, 2014 at 11:49 AM, Kevin Fenzi wrote:
So, sure, we could sign drpms and yum/dnf could check that, but they
still need to assemble the final rpm in order to pass it to rpm.
The question, to my understanding, which may be wrong, is whether the
contents of the assembled rpm need
On Sat, Jun 28, 2014 at 6:54 PM, Orcan Ogetbil oget.fed...@gmail.com wrote:
On Sat, Jun 28, 2014 at 11:49 AM, Kevin Fenzi wrote:
So, sure, we could sign drpms and yum/dnf could check that, but they
still need to assemble the final rpm in order to pass it to rpm.
The question, to my
On 06/28/2014 10:56 AM, drago01 wrote:
On Sat, Jun 28, 2014 at 6:54 PM, Orcan Ogetbil oget.fed...@gmail.com wrote:
On Sat, Jun 28, 2014 at 11:49 AM, Kevin Fenzi wrote:
So, sure, we could sign drpms and yum/dnf could check that, but they
still need to assemble the final rpm in order to pass it
Hi,
I have a very small server room. It has very good network, but lots of
not very powerful computers. Many of them are ARM based.
As I hear about ARM users taking 8 hours to update 1 package (I've had
it take 12 hours to fail to update a package) I irritates me.
The fact that Fedora
Hi
On Fri, Jun 27, 2014 at 10:07 AM, Troy Dawson wrote:
The fact that Fedora practically forces people to use delta rpm's has
rattled my cage for quite a while.
[Snipped]
--- Does it force you to do them like yum does?
[Snipped]
You keep calling it force while acknowledging it is
On 06/27/2014 09:17 AM, Rahul Sundaram wrote:
Hi
On Fri, Jun 27, 2014 at 10:07 AM, Troy Dawson wrote:
The fact that Fedora practically forces people to use delta rpm's has
rattled my cage for quite a while.
[Snipped]
--- Does it force you to do them like yum does?
Hi Troy,
On 27/06/14 16:26, Troy Dawson wrote:
It is a hidden default that is not in any man page or documentation.
Did you look for deltarpm in the yum.conf man page? If it's missing then
that might be the problem (it's there on my x86_64 F20 machines at least).
Cheers,
Andy
--
devel
Hi
On Fri, Jun 27, 2014 at 11:26 AM, Troy Dawson wrote:
It is a hidden default that is not in any man page or documentation.
Yes, I used a poor choice of words.
man yum.conf
deltarpm
When non-zero, delta-RPM files are used if available. The
value
specifies
On 06/27/2014 10:45 AM, Rahul Sundaram wrote:
Hi
On Fri, Jun 27, 2014 at 11:26 AM, Troy Dawson wrote:
It is a hidden default that is not in any man page or documentation.
Yes, I used a poor choice of words.
man yum.conf
deltarpm
When non-zero,
I personally tend to agree with Troy.
We should consider defaulting to disable delta rpm at most, and at
least comment the configs, or make things intelligent.
For me, it takes longer to process delta rpm files than to download
the actual full rpm, even on high end systems, or low end.
I
On Fri, Jun 27, 2014 at 11:07 AM, Troy Dawson tdaw...@redhat.com wrote:
Cool,
I'm glad it's in the man pages now. It isn't in the man pages of my
older versions of yum.
And it's actually a very good section, talking about how it determines
how many threads to use.
Now that we've
Hi
On Fri, Jun 27, 2014 at 12:07 PM, Troy Daws
All that being said, what is the criteria for getting a default
configuration line put into yum.conf?
I'd really like to get the deltarpm= line put in there.
File a bug report in yum bug tracker or Red Hat bugzilla against yum as the
On Fri, Jun 27, 2014 at 6:14 PM, Jon jdisn...@gmail.com wrote:
I personally tend to agree with Troy.
We should consider defaulting to disable delta rpm at most, and at
least comment the configs, or make things intelligent.
For me, it takes longer to process delta rpm files than to download
On Fri, Jun 27, 2014 at 6:14 PM, Jon jdisn...@gmail.com wrote:
I personally tend to agree with Troy.
We should consider defaulting to disable delta rpm at most, and at
least comment the configs, or make things intelligent.
For me, it takes longer to process delta rpm files than to download
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 drag...@gmail.com wrote:
That wasn't about poor as in slow vs. great as in fast but
bandwith capped vs. not.
If building deltas are slow the solution is not to disable them but to
find out why there are slow and fix that. One thing for instance is
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 drag...@gmail.com wrote:
That wasn't about poor as in slow vs. great as in fast but
bandwith capped vs. not.
If building deltas are slow the solution is not to disable them but to
On Fri, 27 Jun 2014 19:18:15 +0200
drago01 drag...@gmail.com wrote:
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 drag...@gmail.com wrote:
That wasn't about poor as in slow vs. great as in fast but
bandwith capped vs.
On Fri, Jun 27, 2014 at 7:21 PM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 27 Jun 2014 19:18:15 +0200
drago01 drag...@gmail.com wrote:
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 drag...@gmail.com wrote:
That wasn't
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 drag...@gmail.com wrote:
That wasn't about poor as in slow vs. great as in fast but
bandwith capped vs. not.
If building deltas are slow the solution is not to disable them but to
On Fri, 27 Jun 2014 19:23:04 +0200
drago01 drag...@gmail.com wrote:
Why?
My understanding of the process as it exists:
Download drpm.
Take drpm contents + old package files installed locally that were not
changed and create updated rpm.
yum/dnf hands off this updated new version to rpm as
On Fri, Jun 27, 2014 at 7:35 PM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 27 Jun 2014 19:23:04 +0200
drago01 drag...@gmail.com wrote:
Why?
My understanding of the process as it exists:
Download drpm.
Take drpm contents + old package files installed locally that were not
changed and
On 06/27/2014 12:28 PM, Dridi Boukelmoune wrote:
It may also be possible to compress-and-sign them on the fly. If the
gpg check can be done incrementally, you could compress the rpm to
/dev/null and gradually compute the signature.
That leaves you a signature to check and a ready-to-install
42 matches
Mail list logo
