-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carl Hartung wrote:
> On Monday 12 September 2005 08:37, houghi wrote:
>
>> This is getting very confusing. I personally like the Yast Repositories
>> better an easier to use:
>> http://www.opensuse.org/Additional_YaST_Package_Repositories
>
> It /is/ confusing to me sometimes, too, so don't feel bad. The way I've
> organized it in my head and on on my systems is YaST handles "official" SUSE
> packages, including the unsupported supplementary sources and security
> updates, and I use apt/synaptic to handle everything else.
Ok, as this topic is poping up quite often, let me give some background on all
that.
YaST2 installs packages from YaST2 metadata repositories. It's as simple as
that ;)
Those are called "installation sources" in the YaST2 jargon.
That "metadata" comprises data for every package that's provided, such as:
- - package name, version and release number, what architecture
- - summary and description
- - dependencies to other packages
- - what it provides to other packages
etc...
Novell provides installation sources for 10.0:
http://ftp.uni-erlangen.de/pub/mirrors/opensuse/distribution/SL-10.0-OSS-RC1/inst-source/
http://ftp.uni-erlangen.de/pub/mirrors/opensuse/distribution/SL-10.0-OSS-RC1/inst-source-java/
(those are from the uni-erlangen mirror, the primary source being ftp.gwdg.de)
Those are the "official", supported installation sources for SUSE Linux, that
include the packages
that are shipped within the SUSE Linux distribution (except for the
"inst-source-java" installation
source: it includes packages that are not shipped on the SUSE Linux OSS
distribution, because
they're not OpenSource, but AFAIK installation of those is also supported by
Novell).
The other installation sources are commonly referred to as "3rd party
repositories", where "3rd
party" means: not made nor maintained nor supported by Novell.
Two examples of these: Packman and my site ("guru") (and there are a few
others, just to lazy to put
them all in here ;)).
We 3rd party repository maintainers have several options on how to "offer" our
packages to
everyone's use:
- - http/ftp download:
Download the files yourself, and install them e.g. with the rpm command-line
("rpm -i ...").
We all have that but it's not the best option as you have to solve the
dependency issues yourself.
- - YaST2 repository metadata:
SUSE includes a few scripts to generate and maintain it (although it's not the
simplest metadata
format to handle, let's hope for/make better tools).
- - APT repository metadata:
To be used by the RPM port of APT (commonly referred to as "apt4rpm" although
that's not correct:
"apt4rpm" is the server-side package that includes the tools to generate the
repository metadata -
the APT client (used to install packages) is "apt" or "apt-get").
- - YUM repository metadata:
YUM is a tool similar to APT that has originally been written by Yellow Dog
Linux (a distro
specialized on PPC) and which has been adopted by the Fedora Core project as
their primary package
installation frontend.
- - RedCarpet repository metadata:
Red Carpet is a package management frontend developed by Ximian (now Novell as
they have been bought
by the latter).
All of these package installation frontends have different repository metadata
formats, which means
that if I, as a 3rd party repository manager, want to give the users the choice
of the frontend they
want to use, I have to generate the metadata for all of them.
And that's what part of us actually do (except for YUM).
Note that for the package repositories hosted at ftp.gwdg.de (and that's most
of them), Eberhart
Moenke does the hard work as he is generating the metadata over there.
For YaST2 and RedCarpet, we are generating it ourselves (at least the Packman
team and I do so).
BTW, I call these (yast2, apt, yum, red carpet) "frontends" because that's what
they are. Not in a
sense of being GUIs(*) or CLIs(**), but because in the end, they all use RPM to
actually install (or
remove, or upgrade) the packages.
(*) Graphical User Interface
(**) Command-Line Interface
The benefit of that approach is that never mind which frontend you use, or even
if you mix them, it
all works just fine because RPM is doing the low-level stuff for all of them.
You don't have separate package databases, it's all RPM.
Note that with "mix", I mean once installing a package with "rpm -i", then with
"apt-get" (or it's
GUI "synaptic"), the next one with YaST2 (or y2pmsh), and eventually the other
one with Red Carpet
(or its CLI frontend "rug").
It all works. So, in the end, it's a matter of choosing the frontend you prefer.
And, obviously, if you have 3rd party package repositories that you like to
use, make sure you
choose a frontend those repositories have metadata for.
...
>> How are these related? Is the above the same as Guru, or are there
>> differences?
It's the URL to the YaST2 metadata ("installation source") but it's the
