It’s nice to see there is hope for a better package management in Fedora…

YUM upstream will soon be considered deprecated, and we will move into a DNF/hawkey/librepo-based future. This includes PackageKit. I’m going to be building a hawkey based backend with help from the maintainer, and he is is aware of what PK does and any unusual tasks that are performance critical.

We should keep old versions of metadata on the server to stop metadata refresh explosions happening where yesterdays primary gets updated because a transaction only has todays filelists installed. This will significantly reduce the amount of bandwidth used by the metadata updates.

We should keep old versions of packages on the mirrors, to avoid the case where we depsolve fine, get 404 on the package download and then have to re-download MD, depsolve, etc. YUM apparently has issues with multiple versions of a package being present in the metadata, so we should probably only reference the latest packages in the MD (which also keeps the MD to sane size).

We should ship the per-arch solv files in the repo MD. This avoids SAT solutions like libsolv from spending 20 seconds+ per repo rebuilding .solv files from sqlite or xml metadata, and allows us to kill the dnf cron job

We should teach rpm to update it’s own SAT database, which we can do with an RPM plugin.

We want a software center, and fedora-tagger can provide the ratings/comments information. We might need an OCS server for screenshots, or can tie in screenshots with automated QA somehow.

We are going to teach koji about appstream data, so a simple extract script (to be written by me) can produce a .tar file of icons and a .xml file of translated descriptions at the end of each koji build

We are going to teach the compose tools to xmlmerge all the appstream .xml files and ship as appstream.xml

We are going to teach the compose tools to join all the tar files and ship as appstream-data.tar.gz

We are going to investigate the use of meta-desktop files to install a super-set of applications, e.g. KDE, or “Python developer” which allows for screenshots, ratings and all that stuff.

Many beginning Linux users experience difficulties getting used to the filesystem structure. Indeed, there are many files and directories, the structure of which are not as obvious as it could be. Choosing an appropriate location for a new file or directory is difficult and many choose to follow their own instincts.

With more experience, the file hierarchy becomes clearer and old concepts of placing files and directories start to fade out. When it happens, finding things becomes difficult. It is than that users learn that Linux has many tools for finding things. And it is than that they become confused once again.

Read on for a quick introduction into searching tools available in Linux.

I’ve just read in LWN about recently announced Fedora Tracker. The goal of the project is to have a central database of apt and yum repositories with search facilities. This sounds like a very nice idea, since finding some Fedora RPM packages is not an easy task.

I’ve check it out and there is plenty of repositories already in. There is also a Submit form for missing information. I wish for this project to live and grow, since it has the potential to be more useful than RPMfind.Net.