SCIENTIFIC-LINUX-USERS Archives

November 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Wed, 25 Nov 2015 00:29:15 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
On Tue, Nov 24, 2015 at 10:12 AM, Troy Dawson <[log in to unmask]> wrote:
>
>
> On Tue, Nov 24, 2015 at 6:01 AM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> ...
>>
>> Debian "apt" has what I think is a more sensible approach to handling
>> the metadata about individual packages, I think. Each package has its
>> own metadata published apart from that package in an individual file,
>> and it's the client system's problem to pull all those and assemble an
>> update list. Someone at Yellowdong, a long time ago, writing the
>> "Yellowdog Update Manager", or "yum", decided that all the packages
>> should have their metadata stored in a single shared database. This is
>> the yum repodata, and it's gotten out of hand since then. The change,
>> addition, or deletion of a single RPM package means that *all* the
>> repodata needs to be rebuilt, and *all* of it transferred.
>
>
> It is a tradeoff.
> yum was originally written like apt, with every rpm having it's own file.
> How often have you downloaded 10,000 little files?

The first time. After that, it's only downloading the new files, and
is far more efficient than always having to download half a dozen
oversized, compressed database files that cannot be incrementally
udpated.

> Takes a while doesn't it.  Takes a long time.  Have you every done it over
> ftp or a dial up connection (or both).  Takes forever.

And that's why "10,000 small files" is better, because you only need
to update the changed ones. If your connection fails on the oversized
yum metadata files, you have to start over from scratch: the
synchronization protocol doesn't support continuing where the last
download broke.

> Have you ever had 1,000 computers all trying to download 10,000 files from
> your file server at the exact same time.  Your server will survive, but
> everything will be a little slow while that is happening.

Yes, I have. It's *much* easier to bandwidth throttle a series of
small connections rather than 1000 monolithic transactions.

> Having lived in the time when yum used everything in it's own file, and
> lived in the time with everything is one (well actually 8) file.  I'll take
> the 8 large files over the 10,000 little ones.

Except that you often wind up dlownloading the same 8 files,
repeatedly, from *every different repository*, which makes them *3 or
even *10 if you have a veriety of repos. SL base, SL fastbugs, SL
security, SLx, EPEL, and rpmfusion are only a few.

> Also, when yum moved to the database style they have now, they worked with
> the apt guys in developing it.  It's just that after yum moved to it, the
> apt guys didn't ... at least not then.  I've lost track nowdays.
>
> Just a little history lesson.

I understand the reasoning. In theory, if they metadata files didn't
tend to expire so quickly, it wouldn't be so bad. But it's gotten out
of hand.and dnf is *not* helping.

ATOM RSS1 RSS2