Seth Vidal Wrote: > On Thu, 2004-11-11 at 09:49 -0700, Kim Lux wrote: >> That was my point: synaptic and apt use rpms. So if I've got a >> dependency issue with apt and synaptic, I'll be having a dependency >> issue with rpms as well. I'd much, much rather use synaptic to take >> care of those issues than doing it manually with rpms. > I understand it is not graphical (yet) but you do know that yum exists, > right? > yum install nameofpackage > it will download and install all the dependencies you need, too. I have used both apt-get for RPM and yum, and I have used both yumi (aka CoBind Manager) and synaptic. From a professional's point of view, synaptic/apt is superior in a number of ways: 1.) Header downloads are faster. I have timed the difference, using the same machine/OS, between a fresh 'yum update' run and an 'apt-get update && apt-get dist-upgrade' run. The apt run consistently finishes in a subtantially shorter amount of time, set up to use the same mirrors as the yum run. The yum run got bogged down in the header downloads. The difference in time was not small; I included DAG's RHEL3 repo in this instance, and, from a scratch WBEL3 respin1 install in both cases, the apt run took nearly two HOURS less time than the yum run. Downloading the headers from DAG took an hour and a half for yum, and less than five minutes for apt. This is on a T1 with a normally low-latency connection to MAE-East; congestion on the local pipe, according to mrtg, was similar during both runs. The machine on which this was running is a Dell PowerEdge 1750 (2.8GHz Xeon, 1GB RAM, 3x36GB 10kRPM U320 drives on a PERC4 RAID controller; machine performance is not an issue). I have duplicated the results for the yum run from home, where I have a DSL connection. I have duplicated the time lag about four times at this point, and a WBEL3r1->fully updated, KDE-Redhatted and DAGified WBEL3 takes approximately three hours to complete. I did virtually the same thing with Scientific Linux and went for SL303->KDE-Redhatted and DAGified SL in about an hour (downloading all the packages is close to an hour on my DSL). So it wasn't just a glitch in DAG's bandwidth. 2.) apt-get install and apt-get upgrade both run from the cache; thus, multiple install runs don't need to refresh the cache each and every run. Yum, OTOH, requires the specific use of -C to do this. Otherwise, each and every yum operation has to go out to the mirrors, refresh the header info, and might have to pull down new headers. Apt seems much faster in this regard. However, you do need to remember to apt-get update when needed, which might be considered a bad thing. 3.)Synaptic is not just head and shoulders better (from a user's point of view) than yumi currently, it is head, shoulders, torso, and legs better. Synaptic allows real package management, including seeing where your space hogs are in a very easy manner (sorting by size). I found yumi to be usable, but just barely so. The system-config-packages isn't even in the same league, since there is little to no documentation or configurability in use of third-party repos and individual package management (at least the last time I used it this was the case, but that has admittedly been a while). If some of synaptic's features can be added to yumi, yumi might be competitive. But the startup lag is so long and slow in non-local repo cases, that synaptic is just simply more of a joy to use because it feels more responsive. Now, synaptic has its own startup lag, but it is typically not as long as yumi's. Synaptic's ability to see into the package dependencies and dependents allows the user to remove packages if necessary in an intelligent manner. Both systems have dependency issues, and a yum repository is easier to set up and maintain. However, apt's configurability allows arcane command line parameters to at least troubleshoot the why of the problems. Yum's configurability is less stellar. I understand yum is intended to be simple, and for keeping a system up-to-date is is an excellent tool, paritcularly with a local repository where the latency issues of setting up a http GET for each and every header doesn't come into as much play as when you are accessing repositories halfway around the world (where it doesn't matter how fast the pipe is: TCP's windowing protocol limits your throughput regardless, and setting up the three-way handshake consumes significant time). In high-latency situations (which, if you are using, say, Scientific Linux and pulling packages from the KDE-redhat project, DAG's RHEL3 repository (in .be-land), and SL's own repository, is significant) yum loses to apt by simple network protocol metrics; apt downloads its large files (which benefit from TCP's window size increase algorithm) more quickly than yum can download its smaller files. Even if there have been few changes in the repository, I have found that an 'apt-get update && apt-get upgrade' sequence will have asked the user's confirmation and started downloading packages before a 'yum update' gets to the point of asking the user's confirmation. That is my experience here over a significant period of time. I tend to use both tools; yum for automatic updates, and synaptic for installing packages, or just seeing what new packages are out there (yumi's interface for installing new packages is not as easy to use as synaptic's: with synaptic, I can right click the package, select properties, and see at a glance what sort of dependencies a package has, see a description, etc). YMMV. And Seth, YUM does work, and it works well for its designed purpose (an updater). I use yum here with a local repository for Aurora Tangerine (SPARCLinux for those not familiar with it) since I have a 20 node Ultra30 cluster (well, not exactly a cluster, but close) running Tangerine. It behooves me to have a local repo in this case, and yum loses less in that instance. Note that these U30's only have 248MHz CPU's, 128MB RAM, and 4GB drives. Yum is faster on these boxes with a local (on the LAN) repo than it is on the Dell 1750 with non-local repos, showing that it seems to be network-bound performance-wise. Or, if you have space for it, a local rsync'd repo is a BIG WIN for yum performance. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu