On Wed, Jul 2, 2014 at 6:04 PM, Reindl Harald 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.
> [harry@srv-rhsoft:~/Desktop]$ t
> 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
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
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 alway
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 Jones
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 29 Jun 2014 20:01:04 -0500
Jon wrote:
> On Sun, Jun 29, 2014 at 7:42 PM, Stephen John Smoogen
> wrote:
> >
> [snip]
> >
> > Personally I would just say don't make delta-rpms for i386 and arm
> > or just have deltarpm=1 on those architectures
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 27 Jun 2014 11:35:20 -0600
Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:23:04 +0200
> drago01 wrote:
>
> > Why?
>
> My understanding of the process as it exists:
>
> Download drpm.
> Take drpm contents + old package files installed local
On Mon, Jun 30, 2014 at 3:01 AM, Jon wrote:
> On Sun, Jun 29, 2014 at 7:42 PM, Stephen John Smoogen
> 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 architectures even.
> This sh
On Sun, Jun 29, 2014 at 7:42 PM, Stephen John Smoogen 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 architectures even.
This should, in my opinion, be disabled by default.
The default-off
On 29 June 2014 15:34, Kevin Fenzi wrote:
> On Sun, 29 Jun 2014 14:20:44 -0700
> Jonathan Dieter 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
On Sun, 29 Jun 2014 14:20:44 -0700
Jonathan Dieter 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 folks think ab
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
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
On 06/29/2014 12:32 PM, drago01 wrote:
On Sun, Jun 29, 2014 at 1:55 AM, Jonathan Dieter 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 sh
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
drago01 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.
Yes, th
On Sun, Jun 29, 2014 at 12:09 PM, Andre Robatino
wrote:
> Rahul Sundaram 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 bu
On Sun, Jun 29, 2014 at 1:55 AM, Jonathan Dieter 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.
> 3. Deltarpm wo
Rahul Sundaram 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. Do
On 06/28/2014 10:56 AM, drago01 wrote:
On Sat, Jun 28, 2014 at 6:54 PM, Orcan Ogetbil 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 questi
On Sat, Jun 28, 2014 at 6:54 PM, Orcan Ogetbil 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 understanding, whic
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 nee
On Sat, 28 Jun 2014 12:51:07 +0200
drago01 wrote:
> On Sat, Jun 28, 2014 at 12:22 PM, Florian Weimer
...snip...
> > The signature is on the RPM header, not the payload. The RPM
> > header only lists digests of individual files (after decompression).
> >
> > So this shouldn't make a difference
On Sat, Jun 28, 2014 at 12:22 PM, Florian Weimer wrote:
> On 06/27/2014 07:13 PM, Kevin Fenzi wrote:
>>
>> On Fri, 27 Jun 2014 19:11:53 +0200
>> drago01 wrote:
>>
>>> That wasn't about "poor" as in slow vs. "great" as in fast but
>>> bandwith capped vs. not.
>>>
>>> If building deltas are slow th
On 06/27/2014 07:13 PM, Kevin Fenzi wrote:
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 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.
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-inst
On Fri, Jun 27, 2014 at 7:35 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:23:04 +0200
> drago01 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
On Fri, 27 Jun 2014 19:23:04 +0200
drago01 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 normal.
If they
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:11:53 +0200
> drago01 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 th
On Fri, Jun 27, 2014 at 7:21 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:18:15 +0200
> drago01 wrote:
>
>> On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote:
>> > On Fri, 27 Jun 2014 19:11:53 +0200
>> > drago01 wrote:
>> >
>> >> That wasn't about "poor" as in slow vs. "great" as in fast bu
On Fri, 27 Jun 2014 19:18:15 +0200
drago01 wrote:
> On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote:
> > On Fri, 27 Jun 2014 19:11:53 +0200
> > drago01 wrote:
> >
> >> That wasn't about "poor" as in slow vs. "great" as in fast but
> >> bandwith capped vs. not.
> >>
> >> If building deltas ar
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:11:53 +0200
> drago01 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 th
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 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
> that it
On Fri, Jun 27, 2014 at 6:14 PM, Jon 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
> the actual f
On Fri, Jun 27, 2014 at 6:14 PM, Jon 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
> the actual f
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
compon
On Fri, Jun 27, 2014 at 11:07 AM, Troy Dawson 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 established that, w
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 suppose
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 n
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
speci
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 maili
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
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 m
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 practical
43 matches
Mail list logo
