On Sat, Nov 8, 2014 at 2:25 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 08.11.2014 um 20:21 schrieb Nico Kadel-Garcia:
[root@rawhide ~]# rm -rf /var/cache/dnf/*
I do think you also flushed all the historical data on what packages
were installed from what repositories
no - that
On Fri, Nov 7, 2014 at 3:31 PM, Reindl Harald h.rei...@thelounge.net wrote:
the meta-data are fat
look below
The metadata are bulky, fairly monolithic databases. They cannot
easily support incremental updates of the metadata because they are
compressed, singular files storing data for all
Am 08.11.2014 um 20:21 schrieb Nico Kadel-Garcia:
[root@rawhide ~]# rm -rf /var/cache/dnf/*
I do think you also flushed all the historical data on what packages
were installed from what repositories
no - that would be
rm -rf /var/lib/yum/*
rm -rf /var/lib/dnf/*
and yes i delete them
Hi
On Fri, Nov 7, 2014 at 1:19 AM, Dennis Gilmore wrote:
/etc/yum.repos.d/fedora-updates.repo on f21 has
metadata_expire=6h
I was looking at dnf since the discussion is about dnf
and the metadata right now for f21 updates is an empty repo with no
packages in it f20 updates repo
Am 07.11.2014 um 17:53 schrieb Rahul Sundaram:
On Fri, Nov 7, 2014 at 1:19 AM, Dennis Gilmore wrote:
/etc/yum.repos.d/fedora-updates.repo on f21 has
metadata_expire=6h
I was looking at dnf since the discussion is about dnf
where do you see DNF using other than /etc/yum.repos.d/
DNF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 6 Oct 2014 08:16:30 -0700
Gerald B. Cox gb...@bzb.us wrote:
On Mon, Oct 6, 2014 at 8:00 AM, drago01 drag...@gmail.com wrote:
I am not convinced that being fast and download less are
mutually exclusive when using deltas. So we should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 19 Oct 2014 22:56:40 -0400
Rahul Sundaram methe...@gmail.com wrote:
Hi
On Sun, Oct 19, 2014 at 9:52 PM, Nico Kadel-Garcia wrote:
It's a rough figure, from
http://mirrors.kernel.org/fedora/releases/20/Everything/x86_64/os/repodata/
On 10/17/2014 05:52 AM, poma wrote:
On 06.10.2014 16:46, Jaroslav Reznik wrote:
- Original Message -
On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote:
Hi
One of the long standing features that were enabled by
On Mon, Oct 6, 2014 at 10:41 AM, Rahul Sundaram methe...@gmail.com wrote:
Hi
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled this and I think this
change deserves a broader discussion
Am 20.10.2014 um 04:02 schrieb Nico Kadel-Garcia:
On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald h.rei...@thelounge.net
wrote:
#!/usr/bin/bash
basearch=`uname
Hi,
3) People who have a lot of hosts and high bandwidth, high speed
local deployment requirements can, and do, set up an internal Fedora
mirror with much lower bandwidth costs.
Maybe mirrormanager can give a hint in case it directs yum/dnf to a
onsite mirror?
cheers,
Gerd
--
devel
On Fr, 2014-10-17 at 11:49 +, Andre Robatino wrote:
Roberto Ragusa mail at robertoragusa.it writes:
Are compressed rpms completely impossible to diff efficiently by rsync?
In a word, yes. They're already compressed, so it's unlikely there would be
any matching blocks between old and
Am 20.10.2014 um 12:31 schrieb Gerd Hoffmann:
On Fr, 2014-10-17 at 11:49 +, Andre Robatino wrote:
Roberto Ragusa mail at robertoragusa.it writes:
Are compressed rpms completely impossible to diff efficiently by rsync?
In a word, yes. They're already compressed, so it's unlikely there
On Sun, Oct 19, 2014 at 11:07 PM, Kevin Fenzi ke...@scrye.com wrote:
On Sun, 19 Oct 2014 21:52:00 -0400
Nico Kadel-Garcia nka...@gmail.com wrote:
It's a rough figure, from
http://mirrors.kernel.org/fedora/releases/20/Everything/x86_64/os/repodata/
(a useful local mirror). Since the number of
On Mon, Oct 20, 2014 at 4:22 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 20.10.2014 um 04:02 schrieb Nico Kadel-Garcia:
On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald h.rei...@thelounge.net
wrote:
Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
On Sat, Oct 18, 2014 at 8:28 PM,
On Mon, Oct 20, 2014 at 6:40 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 20.10.2014 um 12:31 schrieb Gerd Hoffmann:
On Fr, 2014-10-17 at 11:49 +, Andre Robatino wrote:
Roberto Ragusa mail at robertoragusa.it writes:
Are compressed rpms completely impossible to diff efficiently
Am 20.10.2014 um 13:57 schrieb Nico Kadel-Garcia:
On Mon, Oct 20, 2014 at 4:22 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 20.10.2014 um 04:02 schrieb Nico Kadel-Garcia:
On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald h.rei...@thelounge.net
wrote:
Am 19.10.2014 um 06:37 schrieb
On Sun, Oct 19, 2014 at 1:04 AM, Rahul Sundaram methe...@gmail.com wrote:
Hi
On Sun, Oct 19, 2014 at 12:37 AM, Nico Kadel-Garcia wrote:
. And the bandwidth saving is still badly
overshadowed by the necessary repodata bandwith from almost every run
of reposync in the model you've just
Hi
On Sun, Oct 19, 2014 at 3:40 AM, Nico Kadel-Garcia wrote:
Even then, though still means up to 60 MB * 15/month,
Earlier you mentioned 50 MB. Now you claim 60 MB. Can you show where
these figures are from?
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald h.rei...@thelounge.net wrote:
#!/usr/bin/bash
basearch=`uname -i`
releasever=`rpm -q --qf %{version}\n fedora-release`
for g in `ls -1b /var/cache/yum`
do
if [ -d /var/cache/yum/$g/packages ]
On Sun, Oct 19, 2014 at 3:51 AM, Rahul Sundaram methe...@gmail.com wrote:
Hi
On Sun, Oct 19, 2014 at 3:40 AM, Nico Kadel-Garcia wrote:
Even then, though still means up to 60 MB * 15/month,
Earlier you mentioned 50 MB. Now you claim 60 MB. Can you show where these
figures are from?
On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald h.rei...@thelounge.net
wrote:
#!/usr/bin/bash
basearch=`uname -i`
releasever=`rpm -q --qf %{version}\n
Hi
On Sun, Oct 19, 2014 at 9:52 PM, Nico Kadel-Garcia wrote:
It's a rough figure, from
http://mirrors.kernel.org/fedora/releases/20/Everything/x86_64/os/repodata/
That doesn't seem to be the right way to look at the numbers. In a local
system, there are two different repositories enabled
On Sun, 19 Oct 2014 21:52:00 -0400
Nico Kadel-Garcia nka...@gmail.com wrote:
It's a rough figure, from
http://mirrors.kernel.org/fedora/releases/20/Everything/x86_64/os/repodata/
(a useful local mirror). Since the number of packages there changes
day to day, but are likely to increase
On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox gb...@bzb.us wrote:
My comment was not meant to be argumentative, but rather tongue-in-cheek.
However, I do believe when changing a default, it isn't about what is
convenient for me. It's about what is best for the entire community and
what are
On Sat, Oct 18, 2014 at 07:00:19PM -0400, Nico Kadel-Garcia wrote:
3) People who have a lot of hosts and high bandwidth, high speed
local deployment requirements can, and do, set up an internal Fedora
mirror with much lower bandwidth costs. This reduces the tangible
benefits of deltarpms
On Oct 18, 2014 5:00 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox gb...@bzb.us wrote:
My comment was not meant to be argumentative, but rather
tongue-in-cheek.
However, I do believe when changing a default, it isn't about what is
convenient
Am 19.10.2014 um 02:19 schrieb Solomon Peachy:
On Sat, Oct 18, 2014 at 07:00:19PM -0400, Nico Kadel-Garcia wrote:
3) People who have a lot of hosts and high bandwidth, high speed
local deployment requirements can, and do, set up an internal Fedora
mirror with much lower bandwidth costs.
On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 19.10.2014 um 02:19 schrieb Solomon Peachy:
On Sat, Oct 18, 2014 at 07:00:19PM -0400, Nico Kadel-Garcia wrote:
3) People who have a lot of hosts and high bandwidth, high speed
local deployment requirements
Hi
On Sun, Oct 19, 2014 at 12:37 AM, Nico Kadel-Garcia wrote:
. And the bandwidth saving is still badly
overshadowed by the necessary repodata bandwith from almost every run
of reposync in the model you've just described. 50 Megabytes, *every
time* it runs unless the metadata for the repo
On 10/06/2014 07:57 PM, Reindl Harald wrote:
oh no - don't tie all together for reasons which did not destory the world
over years - it is a damned good design that the part dealing with rpm
packages don't need to know anything aboutt delta rpms because the normal
packages are created
On 10/06/2014 07:25 PM, Reindl Harald wrote:
the last discussions suggested that the result needs to be *identical* to the
full RPM downloaded for not break signatures
Bizarre design; the signature should protect the content (uncompressed), not
the transport method (compressed).
--
Am 17.10.2014 um 10:49 schrieb Roberto Ragusa:
On 10/06/2014 07:57 PM, Reindl Harald wrote:
oh no - don't tie all together for reasons which did not destory the world over
years - it is a damned good design that the part dealing with rpm packages
don't need to know anything aboutt delta
Am 17.10.2014 um 10:55 schrieb Roberto Ragusa:
On 10/06/2014 07:25 PM, Reindl Harald wrote:
the last discussions suggested that the result needs to be *identical* to the
full RPM downloaded for not break signatures
Bizarre design; the signature should protect the content (uncompressed),
Roberto Ragusa mail at robertoragusa.it writes:
Are compressed rpms completely impossible to diff efficiently by rsync?
In a word, yes. They're already compressed, so it's unlikely there would be
any matching blocks between old and new rpms for rsync to take advantage of.
(You can verify this
On 10/17/2014 05:09, Reindl Harald wrote:
on a 56kbit modem you don't want to download the full RPMs and on a
150Mbit line the download will always be faster than rebuild the RPM
Perhaps this has already been suggested, but why not ask a question
during the installation of the OS? For
On Fri, Oct 17, 2014 at 2:53 PM, Tom Rivers t...@impact-crater.com wrote:
On 10/17/2014 05:09, Reindl Harald wrote:
on a 56kbit modem you don't want to download the full RPMs and on a
150Mbit line the download will always be faster than rebuild the RPM
Perhaps this has already been
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
bandwith requirements (i.e use deltas) *and* 2) have fast installation
of updates. Those two goals are not mutually
Hi
On Fri, Oct 17, 2014 at 10:24 AM, Tom Rivers wrote:
If the proper configuration can be determined automagically, then by all
means just do it. My point is that users aren't too stupid to understand
bandwidth/processor considerations. The configuration of how much
bandwidth/processor
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
bandwith requirements (i.e use deltas) *and* 2) have fast installation
of updates.
On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius rc040...@freenet.de wrote:
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
On 06.10.2014 16:46, Jaroslav Reznik wrote:
- Original Message -
On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote:
Hi
One of the long standing features that were enabled by default in yum is
support for delta
On 10/17/2014 10:43, Rahul Sundaram wrote:
Wile users might be able to handle such questions (I would avoid
calling them stupid even otherwise)
I didn't call them stupid - in fact I suggested just the opposite. Go
back and read what I wrote.
, it is contrary to the goals of the installer.
Hi
On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote:
I didn't call them stupid - in fact I suggested just the opposite. Go back
and read what I wrote.
I did. You said My point is that users aren't too stupid to understand
bandwidth/processor considerations. I am just saying even if one
On 10/17/2014 05:07 PM, drago01 wrote:
On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius rc040...@freenet.de wrote:
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that
Everyone: please remember the code of conduct here, and advance the
conversation in a productive way or take it elsewhere. Thank you.
--
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
On Mon, Oct 6, 2014 at 8:07 AM, Stephen Gallagher sgall...@redhat.com wrote:
[ . . . ]
It would be nice to see if we can find ways to improve the performance
of the deltarpm reconstruction instead. Much of the time is spent on
compression/decompression tasks which *should* be massively
On Fri, Oct 17, 2014 at 7:24 AM, Tom Rivers t...@impact-crater.com wrote:
If the proper configuration can be determined automagically, then by all
means just do it. My point is that users aren't too stupid to understand
bandwidth/processor considerations. The configuration of how much
On 10/17/2014 06:00 PM, Matthew Miller wrote:
Everyone: please remember the code of conduct here, and advance the
conversation in a productive way or take it elsewhere. Thank you.
Well, then please explain, how you expect people to express fundamental
disagreement with somebody's rationale,
On Fri, Oct 17, 2014 at 5:52 PM, Ralf Corsepius rc040...@freenet.de wrote:
On 10/17/2014 05:07 PM, drago01 wrote:
On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius rc040...@freenet.de
wrote:
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it makes no
Am 17.10.2014 um 17:07 schrieb drago01:
On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius rc040...@freenet.de wrote:
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that
On 10/17/2014 12:11, Gerald B. Cox wrote:
I think you're setting up a false equivalency here. There is a
difference between the requirements of say an XBOX or Playstation user
and that of updating a Fedora system. If given the choice, most
people will say Yes, I have a high speed
On 10/17/2014 11:29, Rahul Sundaram wrote:
On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote:
I didn't call them stupid - in fact I suggested just the opposite.
Go back and read what I wrote.
I did. You said My point is that users aren't too stupid to
understand bandwidth/processor
Hi
On Fri, Oct 17, 2014 at 1:03 PM, Tom Rivers wrote:
If you deconstruct the sentence you quoted above, it boils down to the
subject users and the predicate aren't. Therefore I said quite
specifically that users ARE NOT too stupid to understand
bandwidth/processor considerations. The
On Fri, Oct 17, 2014 at 6:50 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 17.10.2014 um 17:07 schrieb drago01:
On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius rc040...@freenet.de
wrote:
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it
Am 17.10.2014 um 19:45 schrieb drago01:
1) deltarpms - low bandwidth use but takes a while to apply the updates
2) no deltarpms - high bandwidth use but faster updates application.
So now people suggest the user (or the distro) has to either choose 1) or 2) ...
What I am suggesting is adding a
On 10/17/2014 13:19, Rahul Sundaram wrote:
For the last time, my point is that: smart and stupid is not
determined by whether a user understands bandwidth/processor
considerations.
I completely understand that not comprehending all of the complexities
of bandwidth/processor considerations
Hi
On Fri, Oct 17, 2014 at 2:17 PM, Tom Rivers wrote:
I would really like to know how you can equate that with my original
point: Hey, maybe instead of throwing Presto under the bus..
We aren't though. Deltarpms is again enabled by default in Dnf a while
back if you read the bug report.
On 10/17/2014 14:24, Rahul Sundaram wrote:
Deltarpms is again enabled by default in Dnf a while back if you read
the bug report. Everything else has been an tangent, yes.
I suppose I'm having trouble understanding that when you started this
thread with:
On 10/6/2014 04:41, Rahul Sundaram
On Fri, Oct 17, 2014 at 2:44 PM, Tom Rivers wrote:
I suppose I'm having trouble understanding that when you started this
thread with:ble by default for many users. dnf should enable this
configuration by default as well
Yes, that was true when I posted it. As a result of this discussion,
On Fri, Oct 17, 2014 at 9:58 AM, Tom Rivers t...@impact-crater.com wrote:
My point was to say Linux users are usually more tech savvy than XBox and
Playstation users. If they say they have a high speed connection and they
don't and that decision ends up costing them more money in ISP costs,
Ian Malone wrote:
I have an internet flatrate at 150 mbs, and downloading the full rpms
is ALOT faster than the the work that the delta rpms requires.
Wow. Good to see normal users are taken into account.
I have a normal Austrian broadband connection, and it is still much faster
to just
On Thu, Oct 16, 2014 at 8:00 AM, Kevin Kofler kevin.kof...@chello.at
wrote:
And parallelization (as others in the thread have suggested) will not help
at all on the single-core machine I'm typing this on.
Single-Core? Really Kevin? Even the One Laptop Per Child machines are
dual-core. ;-)
Gerald B. Cox composed on 2014-10-16 12:52 (UTC-0700):
Kevin Kofler wrote:
And parallelization (as others in the thread have suggested) will not help
at all on the single-core machine I'm typing this on.
Single-Core? Really Kevin? Even the One Laptop Per Child machines are
dual-core.
My comment was not meant to be argumentative, but rather tongue-in-cheek.
However, I do believe when changing a default, it isn't about what is
convenient for me. It's about what is best for the entire community and
what are the real world ramifications. I'm not buying the let's change
the
On 10/17/2014 05:40 AM, Gerald B. Cox wrote:
My comment was not meant to be argumentative, but rather
tongue-in-cheek. However, I do believe when changing a default, it
isn't about what is convenient for me. It's about what is best for the
entire community and what are the real world
On Mon, Oct 6, 2014 at 9:55 PM, Jonathan Dieter jdie...@lesbg.com wrote:
On 10/06/2014 08:57 PM, Reindl Harald wrote:
Am 06.10.2014 um 19:45 schrieb Florian Festi:
The way of getting around all this unnecessary computation is
establishing trust via the deltarpm itself and giving up the idea
Hi
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled this and I think this
change deserves a broader discussion
https://bugzilla.redhat.com/show_bug.cgi?id=1148208
Rahul
--
devel mailing list
Hello All!
2014-10-06 12:41 GMT+04:00 Rahul Sundaram methe...@gmail.com:
Hi
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled this
At last!
--
With best regards, Peter Lemenkov.
--
devel mailing list
On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote:
Hi
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled this and I think this
change deserves a broader discussion
On Mon, Oct 06, 2014 at 04:41:07AM -0400, Rahul Sundaram wrote:
Hi
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled this and I think this
change deserves a broader discussion
Am 06.10.2014 um 13:00 schrieb Richard W.M. Jones:
On Mon, Oct 06, 2014 at 04:41:07AM -0400, Rahul Sundaram wrote:
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled this and I think this
change deserves a broader
On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote:
Hi
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled this and I think this
change
On Mon, Oct 06, 2014 at 12:00:04PM +0100, Richard W.M. Jones wrote:
The amount of time taken to rebuild rpms from delta rpms meant that
they didn't seem to save anything for me.
It's not about saving *time*; it's about reducing the amount of data
sent over the wire -- this is particularly
On Mon, Oct 6, 2014 at 3:07 PM, Stephen Gallagher sgall...@redhat.com wrote:
On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote:
Hi
One of the long standing features that were enabled by default in yum is
support for
Hi,
It would be nice to see if we can find ways to improve the performance
of the deltarpm reconstruction instead. Much of the time is spent on
compression/decompression tasks which *should* be massively parallel
s/massively parallel/not done at all/ ... but we had this discussion
On Mon, Oct 6, 2014 at 3:48 PM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
It would be nice to see if we can find ways to improve the performance
of the deltarpm reconstruction instead. Much of the time is spent on
compression/decompression tasks which *should* be massively parallel
- Original Message -
On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote:
Hi
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled
On Mon, Oct 6, 2014 at 4:46 PM, Jaroslav Reznik jrez...@redhat.com wrote:
- Original Message -
On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote:
Hi
One of the long standing features that were enabled by
On Mon, Oct 6, 2014 at 8:00 AM, drago01 drag...@gmail.com wrote:
I am not convinced that being fast and download less are mutually
exclusive when using deltas. So we should keep deltas *and* make them
faster.
Exactly. The fact that some users have more bandwidth means exactly what?
Most
On Mon, 06 Oct 2014 09:07:33 -0400
Stephen Gallagher sgall...@redhat.com wrote:
The deltarpms were meant to serve two purposes
1) (lesser) Address the needs of users in developing countries (where
Fedora is fairly popular) and bandwidth concerns are very
considerable. Many of these users
FWIW, I wrote and maintained yum-presto before it was integrated into
yum. I've commented inline:
On 10/06/2014 06:31 PM, Kevin Fenzi wrote:
On Mon, 06 Oct 2014 09:07:33 -0400
Stephen Gallagher sgall...@redhat.com wrote:
The deltarpms were meant to serve two purposes
1) (lesser) Address
On 10/06/2014 05:16 PM, Gerald B. Cox wrote:
The fact that some users have more bandwidth means exactly
what? Most people also have faster processors and disks now. It is
more efficient from a networking perspective to minimize unnecessary
traffic and use local processing. That was behind
Bandwidth may be growing faster, but it started way behind processing
power. It hasn't caught up. The current definition from the FCC for
broadband is 4Mb. They are working to increase it, but that hasn't
happened. Carriers are looking for ways to throttle traffic. Your
assumption that
because it needs to build the complete xz-compressed RPM
there was a discussion here not that long ago
Is the XZ the only option for RPMs now? Can't it do it uncompressed? Or
at least gzip -1.
Or Rich can add new feature to his ultra-blazing-fast multi-core XZ
decompressor. Compression :-)
--
Am 06.10.2014 um 19:18 schrieb Lukas Zapletal:
because it needs to build the complete xz-compressed RPM
there was a discussion here not that long ago
Is the XZ the only option for RPMs now? Can't it do it uncompressed? Or
at least gzip -1.
Or Rich can add new feature to his
On Mon, Oct 6, 2014 at 7:01 PM, Florian Festi ffe...@redhat.com wrote:
On 10/06/2014 05:16 PM, Gerald B. Cox wrote:
The fact that some users have more bandwidth means exactly
what? Most people also have faster processors and disks now. It is
more efficient from a networking perspective to
Ok I think the above thread explains it, the Jonathan's mail lists what
would be needed and it looks like there are some blockers on the infra
side. Disregard.
--
Later,
Lukas #lzap Zapletal
--
devel mailing list
devel@lists.fedoraproject.org
On 10/06/2014 06:53 PM, Jonathan Dieter wrote:
Get to coding. ;)
As mentioned elsewhere, the problem *is* signatures. yum (quite
rightly) refuses to install an rpm whose signature doesn't match the one
in the primary repodata. And I believe that the signature in the RPM is
also over the
Am 06.10.2014 um 19:45 schrieb Florian Festi:
On 10/06/2014 06:53 PM, Jonathan Dieter wrote:
Get to coding. ;)
As mentioned elsewhere, the problem *is* signatures. yum (quite
rightly) refuses to install an rpm whose signature doesn't match the one
in the primary repodata. And I believe
On 10/06/2014 07:53 PM, Jonathan Dieter wrote:
As mentioned elsewhere, the problem *is* signatures. yum (quite
rightly) refuses to install an rpm whose signature doesn't match the one
in the primary repodata. And I believe that the signature in the RPM is
also over the whole compressed rpm.
On 10/06/2014 08:57 PM, Reindl Harald wrote:
Am 06.10.2014 um 19:45 schrieb Florian Festi:
The way of getting around all this unnecessary computation is
establishing trust via the deltarpm itself and giving up the idea of
reconstructing the originally rpm as a prove of everything worked out
92 matches
Mail list logo
