file dependencies and packages and [blocker] bugs

Andrew Farris lordmorgul at gmail.com
Tue Mar 4 00:54:19 UTC 2008


Nicolas Mailhot wrote:
> Le lundi 03 mars 2008 à 14:56 -0800, Andrew Farris a écrit :
>> Nicolas Mailhot wrote:
>>> Anyway the whole argument stinks. Yes filelists make transactions
>>> slower. However these particular file deps will only cause the file
>>> lists to be pulled when one of the aforementionned badly coded marginaly
>>> used games is installed or updated so
>>> 1. this won't happen for the vast majority of users or updates
>> Yes you're right my prior email was a bit broad, but the game packages may not 
>> be the only ones doing something of this nature with filedeps that could be avoided.
>>
>>> 2. the costs are paid by the users of the problem packages
>> No, the 'costs' are paid by mirrors serving bandwidth for users with those 
>> packages installed.
> 
> Server-side it's the same whether you serve a volume of data as part of
> a package or as part of a filelist.

Not exactly true.  The filelists being pulled are not carrying the data that may 
be updated.  If you pull the filelists to depsolve and then update the package, 
you're still transfering both.  If you move the font into the package (as an 
example) it is a smaller file than the filelists, and what you pull down is the 
data you're updating.  The excess is the size of the filelists which is bigger 
than a font or two.  You did not need the filelists.

> What annoys Seth is volumes served
> as part of filelists are counted in the "yum is slow" column, while the
> same volumes served as part of packages are counted in the "packages are
> bloated" column.

Maybe so, but that doesn't mean others shouldn't care about the bandwidth.

> However dependencies are the heart of a package system, and by trying to
> ban a kind of dep which is widely used in the rpm word you're not making
> yum/rpm as fast as apt/deb you're making it as annoyingly limited.

I think the question is whether it is wise to use the filedep in every situation 
just because the capability exists and the file is provided by another package, 
or if there is a better way to go about it in most situations.

> Now, the problem with file deps is not that they exist but that the
> complete filelists are huge and limiting file lists to some filesystem
> areas does not really work (or we wouldn't have this discussion, and
> remember the rpm/Fedora ecosystem is not limited to Fedora packages even
> if the filedep purge succeeded Fedora-side)
> 
> Therefore, instead of periodically trying to eradicate file deps (which
> meets some opposition), why not try to make the file deps *as* *used*
> *within* *Fedora* fast? Alternative packager-friendly solutions would
> be:

I'm not arguing against any better solution, only against not considering a 
solution at all.  It appears to me to be a problem that will only escalate as 
the size of the Fedora package space continues to grow (so the filelists are 
bigger).  Those suggestions seem reasonable, particularly a multilevel filelist 
(seems to work nicely for filesystems).

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----




More information about the devel mailing list