Re: dependency hell
- From: David Bolt <blacklist-me@xxxxxxxxxx>
- Date: Sat, 22 Dec 2007 14:32:04 +0000
On Sat, 22 Dec 2007, Paul J Gans wrote:-
David Bolt <blacklist-me@xxxxxxxxxx> wrote:
On Fri, 21 Dec 2007, Paul J Gans wrote:-
takeout <user@xxxxxxxxxxx> wrote:
But I don't want to debate.
Then why post? You're going to get a debate whether you wanted one or
not.
Of course. What was clearly meant was that I was not going to
write 10 posts saying the same thing over and over again.
I thought that was one of the purposes of Usenet.
I think it is a problem and just said so in a previous post.
Or a few dozen previous posts.
Over a period of a year or so.
Something like that, yes.
If you look closely at the conflicts, the installation of *some*
packages causes real conflicts. But many of the other conflicts
are just bunk.
Like? Do be specific then we can look and see if the conflicts really
are a load of bunk, or not.
I was specific.
No, you said some conflicts were bunk. You didn't say _which_ conflicts
you thought were bunk. That was what I meant by be specific.
You're entitled to that opinion. I think it was a case of you not
thinking what the goal was and finding a way to it. There are many ways
to one point but none of them involve sitting there and bitching about
how the choices SUSE made for what they believed was the most likely
satisfy the most users were not the perfect ones for you.
I'm sorry, but you have missed the point. It is not that
it *can't* be done. It is that there is no reason to have
to do it.
They designed their patterns so they would provide the maximum usability
to the less advanced, and/or home users.
You will admit, I think, that just because openSUSE bundled
unrelated things into "patterns" they are not necessarily
depenedent on each other.
The patterns aren't there to provide all the software that is dependent
on each other within the one pattern. They're there to provide a certain
functionality, and the packages contained within that pattern will
provide that functionality.
So the dependency isn't based upon what a specific package provides, but
on what the pattern as a whole provides.
That being true, then why does YAST insist that there is a
depedency there?
It says it's there because the pattern says it's required to perform the
function the pattern is designed to provide. If one of the packages that
was required to provide that function isn't there, then that function
can't be provided.
This is a serious bug. The dependency
of program A on program B means that A will NOT run without
B being present.
Patterns != Packages
Pattern A requires program B, C and D to provide the function it is
designed to for. If you don't want to use program C, for whatever
reason, then pattern A is going to be broken.
That is clearly not the case with programs
in openSUSE patterns.
You're mixing up patterns with packages. They're not the same thing.
Just stop and think about that. Patterns are NOT dependencies.
Patterns provide a list of packages that it depends upon. Don't install
one of the packages and there is a broken dependency. The fact that you
could install almost all the packages listed in the pattern, and not the
pattern itself, while still having the same functionality, is neither
here nor there.
Further, I was not talking about my problems with Firefox. I
was noting that Firefox in 10.2 is an example of a program that
can't be removed because of dependency hell.
It could be removed. A little lateral thinking was required to do so,
but it was easily solved.
The Gimp is another
example.
Yes, I can work around them. And you were of help by pointing
out to me that openSUSE considered members of a PATTERN to be
dependent on each other. Once that was understood, the rest
was easy.
It's not the _members_ of a pattern that are dependent on one another,
nor do the packages depend on the pattern. The pattern depends on the
members, and all the members can be installed without the pattern being
installed.
But it is still a bug. Worse, it is a bug that many other
distros do NOT have.
I don't think it's a bug. It's a feature that is quite useful. I say add
just one pattern and a number of others are brought in to fulfil the
requirements. If required, I can go a customise the packages that are
installed, maybe removing one package I don't want and replace it with
another. One that I always have to do is to replace Postfix with
Sendmail, because SUSE changed the defaults years ago. It's a minor
annoyance, but one I can easily live with.
I like openSUSE. That's why I use it. That does not mean
that it is above criticism or that it has not problems.
Find something that doesn't have problems and I'll show you something
that nobody uses.
I do not think that there is a real dependency data base.
There is. Just look at packages.gz files in the repositories. Those list
the dependencies for each package in the repository, including all the
requires and provides, so the dependency solver can sort them out.
No. This is not true.
Yes it is.
As you just said pointed out ALL members
of a pattered are given as dependent on each other.
No, I said the pattern depends upon the packages listed within it, some
of which may also depend on other included packages. I didn't say that
ALL the packages depended upon each other, or that they all depended
upon the pattern.
That means
that it is not a true dependency data base.
Look at the contents of the packages.gz file some time. What you'll find
is that it is a list of all the packages contained within a particular
repository. It contains a full list of what each package provides, what
each package requires, and what they conflict with. The database is then
created from that list.
Working out true dependencies is quite difficult. Some dependency
chains may be circular, thus in fact making removal of any one
member of the chain impossible.
Those can be annoying.
A pattern lists several packages that are required to install that
pattern. It also lists suggested packages, that would possibly enhance
one of the other packages. It also lists the conflicts, so you know that
you can't install that pattern if it conflicts with another. There's
nothing that stops you from installing any of the packages that are
listed in a pattern and not installing the pattern itself.
Huh? Of course you can do that. But *IF* you install the entire
pattern, openSUSE complains about the removal of any one of them.
That's dependency hell. You've been in it yourself.
Sometimes it does, sometimes it doesn't. If a package is
Worse: during an initial install the system wants to autoinstall
a bunch of patterns.
That would be the default install, probably either a Gnome or KDE
desktop installation. And yes, there are a lot of patterns it wants to
install.
During that install, one has other things
on one's mind than going through several hundred programs to decide
if one wants them or not.
Why? If you cared enough you would spend the time to ensure you had the
system you wanted from the start.
I have also suggested, long ago, that one install choice should
be to install a minimum setup automatically. This should result
in a bootable system able to do updates and further installs.
Now that one knows that the install worked (it doesn't always),
one can go ahead and select packages to install.
If you want to do it that way, that's your choice. All it requires is
selecting a minimal graphical installation and, once that's completed,
build on from there.
As it is with 10.3, which I've installed on four machines so far,
I did the first two in two stages. I made sure the install worked,
erased the install and redid it, this time being careful about my
selection of packages. I should not have to do that.
You didn't have to do that. You could just as easily spent the time to
do it right the first time.
On the other hand, I think it would be difficult to build and
maintain a real dependency data base.
If you mean one that consist of every package available, you're not
going to see one of those. The closest you're going to get is the one
created by zypper from all the different repositories it's told about.
No. That is not what I mean. First, take out the core libraries
that must (or should) be present. They are needed by (almost)
everything.
In which case they should still be listed in this database.
Beyond that most packages do not have very many
dependencies. The dependency database should list only those
needed dependencies.
It should and, to the best of my knowledge, that's what it does.
There is, for example, nothing in 10.2 or 10.3 that NEEDS firefox.
Thus one should be able to remove it without any complaints.
With 10.2, it did require some effort to remove Firefox, but it didn't
require that much. With 10.3 it can be removed very easily.
Yast
installed it, yast should be able to make it go away.
As I said, with 10.2 it required a bit of work to do. With 10.3 I could
do it three ways:
rpm -e
zypper rm
YaST2 -> Software -> Software Management
The first two require some typing, the last requires either several
key-presses, or a few key-presses and mouse clicks.
However, as I said above, it *is* possible to have circular chains
of dependencies. Those are impossible to break.
Even circular chains of dependencies can be broken. I've done it a few
times when updating some software, and the system has ended up in a
non-broken state with all the dependencies correctly satisfied.
Regards,
David Bolt
--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a0
SUSE 10.1 64bit | openSUSE 10.2 64bit |
RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC |RISC OS 3.11
.
- Follow-Ups:
- Re: dependency hell
- From: Ian Lincoln
- Re: dependency hell
- From: houghi
- Re: dependency hell
- References:
- dependency hell
- From: takeout
- Re: dependency hell
- From: houghi
- Re: dependency hell
- From: takeout
- Re: dependency hell
- From: Paul J Gans
- Re: dependency hell
- From: David Bolt
- Re: dependency hell
- From: Paul J Gans
- dependency hell
- Prev by Date: Re: Graphics problem
- Next by Date: Re: dependency hell
- Previous by thread: Re: dependency hell
- Next by thread: Re: dependency hell
- Index(es):
Relevant Pages
|
|
