Thanks Michael;
On Wed, 2008-01-16 at 14:41 +0100, Michael Schwendt wrote:
> On 15/01/2008, William Case wrote:
[snip]
> >
> > I have used almost all of the various commands and utilities yum has to
> > offer, but would like to understand what is happening at some more basic
> > level that doesn't involve diving into source code.
> >
> > Any suggestions? Hoping some one else has been there and done that, and
> > can give me a quick tip or some search criteria.
>
> If memory serves correctly, Seth Vidal has given at least one talk
> about Yum at one of the FUDCons. Perhaps with some searching you can
> locate the slides (if any) in some archive.
>
> Your question is quite vague. It doesn't become clear what level of
> detail you are interested in.
>
Yes I suppose it was. I was trying to avoid a request that would take
up more time than necessary for respondents. Sometimes, when one is
trying to dive in to, trying to figure out how , a process functions one
does not have the 'a priori' knowledge to form the question precisely.
What follows is the kind of question I was asking myself. I am not
asking for a precise response, but some means that I can study and read
to find the answers myself.
> The interaction between Yum, package metadata and RPM should be fairly
> obvious.
In this case, what is metadata? Where is it on a file (package) and how
does Yum read it?
> Yum accesses local or remote repositories, which usually are
> normal http/ftp servers
Does it use its own specialized instructions to access data or does it
use some version of 'wget'?
> that contain RPM packages plus the
> corresponding metadata archives generated by the createrepo tool.
How does the creatrepotool create an archive? What is needed etc?
> The
> metadata describe the available packages beyond the information
> available in the filenames and without the need to download full
> packages. Basically, many data from a file's RPM package header (such
> as name, epoch, version, release, arch, excludearch and exlusivearch
> lists, dependency details, package capabilities, virtual package
> names, library SONAMEs, obsoletes, conflict definitions, but also
> filelists) are copied into the metadata archives, but in a format that
> is more convenient and faster to parse, e.g. xml or sqlite files.
I suppose analyzing how createreptool creates an archive answers most of
the metadata questions? Where would I find an *explanation* of how to
go about creating a repo or a package for a repo?
> Having learned what packages are available in the repositories, Yum
> queries the local RPM database to examine what packages are installed
> already.
Where, and more importantly what is the info regarding each package
stored in the local RPM database? How does yum find it and read it?
> Combining the information it is able to determine what newer
> packages are available as updates which is Yum's primary purpose.
> Since updates can also replace other packages or require new packages
> to be added, there's quite some time spent on processing and resolving
> lots of package metadata. For any packages to be installed, it either
> downloads them via the network or accesses them locally. It then uses
> the RPM library to examine a transaction set of packages further in
> order to find out whether there are any dependency problems or
> conflicts before asking RPM to perform a transaction.
That was what prompted the question in the first place. As I watch yum
or yumex install updates, it appears to be downloading to a temp
directory; running some kind of check; then completing the transaction
and cleaning up afterwords. If this is the case:
* What precisely is a package?
* What and Where is this temp directory?
* What checks are it running (you have alluded to them above)?
* What exactly is a *transaction*?
* What does cleaning up (cleanall etc.) mean? Is something being
removed or just changed?
As I said above, I don't want to waste anybodies time with long detailed
explanations, but it seemed obvious to me that from the detail and
accuracy of answers that some members of this list are able to give
concerning issues with yum; they have learnt how yum works. I wanted to
acquire some of that knowledge -- at least as an overview.
> That's only a
> very brief coverage of what Yum does.
And, I would like to get the long version -- if anyone can help?
--
Regards Bill
