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@xxxxxxxxx> 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
---- ----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
