[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pup: boon or curse? quicker updates or slower updates?

I suppose this is a fair enough assumption. But, unlike 'cd', 'ls', etc
which perform _immediately-required_ actions, 'apt-get update' (from a
semi-newbie point of view) does nothing tangible. (Think: "It's updating
the repository information? What's that? Why is this needed? Why can't I
just install the program?") So unlike the basic commandline commands,
the "apt-get update" command gives no immediately obvious results to
someone coming from, say, That Other OS. Explaining to them what
"apt-get update" does is usually pointless, as they do not always
understand and definitely don't care. They _just want it to work_.

Such people should be using the GUI, and not the CLI. If the GUI
prompts that the metadata has gone stale then it can prompt the user
nicely. Maybe Puplet can do something like this. At the same time you
do not realise how painful it is to explain to people why Yum is so
slow in starting to do something than apt or Synaptic. Forget about
Windoze users, even existing GNU/Linux (read Ubuntu) users are not
convinced about Yum.

Oh, and you'd be surprised at how many "newbies" use/want to use the
command line (see comments about the yum gui below)...

Then the GUI needs to be fixed. :-) No use asking the CLI to cover up for that.

Fair enough, but if you know what you're doing, then why not simply use
something like "yum -C update"? This does the same as "apt-get upgrade",
i.e. it runs from the local metadata cache.

I was just informed by Jeff Spaleta on a private mail that the
introduction of metadata_expire has almost obsoleted the use of 'yum
-C...'. Moreover I read that 'yum -C...' needs the packages to be
present in the cache too. Thus it is only useful for 'yum list', 'yum
search', etc..

GPG key ID: 63D4A5A7
Key server: pgp.mit.edu

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]