I have been using YUM (and Pirut) on various versions of Fedora Core for the past two or three years, and have some ideas to improve certain aspects of it. I apologise for the cross-posting, but I figure that this might be relevant to both the lists. 1. Enabling users to make 'yumpacks': This is inspired by https://wiki.ubuntu.com/OfflineUpdateSpec to enable users of YUM (and Pirut) to be able to install/update from packages downloaded on a different machine on a standalone offline machine or one with very harsh bandwidth constraints. Users having more than one machine, which are not on a LAN, can also be benefitted since they need not download the same things everywhere. It is true that the samething can be done using: a. yum deplist b. wget c. createrepo d. yum localinstall e. yum localupdate However for those who are not conversant with the working of YUM, Pirut, RPMs, dependencies, repositories, etc. will find it quite difficult to do it. With the growing popularity of GNU/Linux on the dektop, this is no longer a trivial issue. Some use cases can be: a. Manu has two machines-- one at work and one at home. The former is blessed with a nice Internet connection, while the other one is a standalone machine. Manu has just installed Fedora Core 6 on both his machines but does not really know much beyond 'yum install' and 'yum update', and his heavily dependant on the GUI since he is not a geek. He loves the system, and wants to install his favourite media player on his home machine. He has it on his office box, but the lack of Internet connectivity at home is a problem. He has read some material about making YUM repositories, but what he would love is a simple interface to do the whole thing. eg., "yum makepack <mediaplayer>" or a click and go feature in Pirut. Once the pack is made and saved in the desired location he can care it home on his pen-drive and enjoy the latest movie with his wife and kids. b. Rakesh has five different machines and they are not on the same LAN. Although both are connected to the Internet, the bandwidth is not of the best quality. Downloading the same updates and packages on both machines is quite a pain. He wants a simple facility by which he can create a 'yumpack' everytime he installs or updates something on one machine, so that he can use the same 'yumpack' to repeat the installation or update on his other boxes. c. My grandmother is fascinated by the talk of Free Software. She wants to try out Fedora. She does not know much about computers, and it is not possible to teach her about YUM caches, repositories, dependencies, etc.. She also finds it difficult to figure out what package to install using YUM and Pirut. I want to give her a 'yumpack' on a CD containing the packages she wants to have on her desktop, so that all she has to do is ask YUM or Pirut to install whatever is there in the pack. She just has to remember one command-- something like: "yum usepack <pathtopack>", and not "yum install <package1>", "yum checkupdate", "yum -y update", etc.. 2. I recently learned that it is possible to download deltas of RPMs instead of the whole package. Exploiting this feature in YUM (and Pirut) can be extremely beneficial in conserving bandwidth and cache size. Making 'yumpacks' (see point 1) can will also become quicker and result in smaller packs being made, since one would not need to download and put the entire RPM in the pack if the currently installed version of the package is known. I have heard deltarpm does something like this, but have not come across something in YUM or Pirut which makes use of this. Some use cases: a. Arjun has a very slow connection to the Internet which is not available 24x7. Everytime he does "yum -y update", the slow network ensures that he has to keep his machine on for hours. Even then he experiences time-outs while downloading large packages (say >2M) and because the Internet is not available 24x7 this makes things more difficult for him. Arjun badly wants to circrumvent this problem. He wants to upgrade package 'foobar' and the RPM is 20M. However the only change as compared to the one he already has is a small, but critical segmentation fault problem. So it would be really good if he can somehow download a small diff and patch his installation using YUM (and Pirut). b. Ranjeet wants to give his brother all the latest RPMs in the updates repository. However they take up too much space to fit on a CD. Ranjeet does not have a DVD-RW drive so he has to use multiple CDs. Since his brother regularly updates his box, all that is needed are the diffs and not the entire packages. Ranjeet can make smaller repositories (or 'yumpacks') for his brother if he and his brother can use the diffs in YUM (and Pirut). 3. A "apt-get update" and "apt-get upgrade" combination for YUM and a 'refresh package information' for Pirut, so that the package information is updated only when explicitly stated by the user. However I do not know whether this is already available in YUM (and Pirut) or not. What I have learned is that the 'metadata_expire" value in yum.conf is used to decide when the meta-data is marked stale. The usual default setting of 1800s is too low and effectively every time someone starts YUM (or Pirut) it starts downloading the full package information from the remote servers. With the exception of extremely quick networks, this causes YUM to take a long time to actually start doing something. Pirut gives the impression of having hung or crashed. The more repositories you have enabled, the more enhanced is the problem, making these aplications (especially Pirut) almost unusable. Increasing the 'metadata_expire' value to something like 24*10*3600 can work, but for novices this is difficult to figure out and in my opinion is not an elegant solution. A use case: a. Vivek has just shifted to Fedora from Ubuntu/Debian. He tries out Pirut and is apalled by the amount of time it took to display the packages list. He badly misses the feature in Synaptic which enabled him to update his package information only when he desired to. Same applies for YUM too. Phew! That was long, but did I make any sense? Comments? I know Python and would love to help out in developing any of these features if you find them useful. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
