On 08/28/2009 01:27 PM, 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!
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.
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).
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.
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.
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.
[1] http://www.fedoraproject.org/wiki/Features/MediaRepo
Thanks anyway,
Hedayat
Since it's idea time, I think it would be good for the user that uses
yum to see in a listing (like yum search <$whatever>) to see the status
of the package, like installed, not installed, virtual package et al.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
