On Fri, 28 Aug 2009, Hedayat Vatnakhah wrote:
Hi all,
Currently, Fedora package management is one of the most annoying part of
Fedora experience for new desktop users (at least for those without fast,
always available internet connection). For such users, Fedora package
management "Just Doesn't Work"! I've almost never been able to demonstrate
using fedora package management tools for a fresh Fedora install without the
need to use command line, editing yum configuration file(s), killing current
running yum/package kit instance(s), installing some small rpm packages using
rpm command instead of using yum or graphically, etc. And sometimes, I found
it better to download yum metadata using another application and copying the
downloaded file to yum cache; or even completely skip yum and use rpm and
manually resolve dependencies when they are not too much!
Have you filed bugs on any of these issues or are they strictly due to
unreliable network connections?
First, I've some suggestions/requests which doesn't seem to need much work,
and then some ideas which I'd like to know your opinions about.
1. Since Fedora 4, Fedora doesn't support installing software from DVD "out
of the box". Fedora 8 is an exception here. Currently, it seems that the work
is almost done (99% completed as in [1]), and fixing the remaining 1% doesn't
seem to need much work but unfortunately it seems that it is stopped. I think
requesting a small collaboration between the feature owner, PolicyKit and/or
GIO people is not too much.
Alsadi has done a great deal of work to make this happen and I believe it
is likely it will go in for F13.
2. Maybe yum could be a bit more forgiving about inaccessible repositories
when running. Consider this case: a new offline user installs Fedora, and
then runs "Add/Remove Software". Currently, if he clicks on "all packages",
he'll see an error message that yum is unable to contact fedora repository. I
think it is better to show a warning to user about being unable to contact
online repositories and then show all installed packages + the packages from
all accessible repositories. IMHO it is much more reasonable than expecting
the user to disable all such repositories in such cases (yum/packagekit can
be a bit more intelligent and do it itslef).
Disabling repos which are unavailable/inaccessible is a pretty dangerous
behavior. If you're doing a 'yum install foo' and the only 'foo' you have
access to is insecure - but a secure 'foo' is in the updates dir - it
would be better for you to not install 'foo' at all than install a bad
one.
Now, some ideas:
3. AFAIK, currently yum's primary database file contains information about
packages, and all of the files in directories such as /usr/bin and /usr/lib,
so that it can resolve package and file level dependencies. Isn't it possible
to move file level information outside primary db (e.g. to
primary_file_deps.db) and translate internal dependencies from file level
dependencies to package level dependencies when creating repositories? (So
that provides and requires tables in primary db only contain package
references rather than file references?). It might be even possible to do it
for dependencies outside repository; for example when creating updates
repository, you can introduce fedora repository to createrepo, so it can
translate all of the file level dependencies of updates packages also.
Except none of this will work for dependencies for 3rd party repos at all.
Nor will it adequately handle any of the cases where we have multiple pkgs
which provide the same file.
4. Even if the above solution is possible and can reduce the size of primary
db, it won't solve the main problem: for large repositories, you'll need to
download large database files. You'll need to download extra database files
on some use cases anyway. So, it can be said that currently yum doesn't scale
well.
no - it can be said that yum if you have a lot of pkgs you have a lot of
metadata. That's not a function of yum scaling that's a function of
network connectivity.
What do you think about it: we can implement parts of yum at the server side
(e.g. a web service), and do queries online. The client can submit queries to
online repositories, aggregate the results (+using local repositories by
itself) and do appropriate actions. It can also store received data to be
used when offline or while they are valid. It'll be completely backward
compatible with the current clients: those who use the old method can
download repositories themselves, like what they do now.
It is possible to think about further details and design it completely, but I
want to know about your opinions about the whole idea.
That's what up2date and rhn did in rhl6->rhel3. There are multiple
problems:
1. we need a single web service that many systems would access to
query for depsolving If you want to talk about things NOT scaling....
2. it would mean anyone wanting to do a respin couldn't just setup a
website or an ftp mirror or a file:/// repo - they'd have to setup a web
service and populate it. That's some pretty serious overhead.
3. 3rd party repos would have to go through a whole other level of hoop
jumping.
Now, I don't think anyone is opposed to seeing some of these things but
given what you've said on the yum-devel mailing list (where much of this
discussion should be anyway) you don't seem to be interested in actually
working on it or have the time. Did that change?
-sv
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
