Stuart wrote:
"Tom Horsley" wrote:
I have seen lots of admonitions about the dangers
of mixing packages from, for example, livna and
dries. But I have not seen any clear technical
descriptions of exactly *what* (with examples) the
problem is!
You download mplayer from livna, all is working. Then
you add freshrpms to get something from there that
livna doesn't have, and it starts updating your
mplayer libraries. Pretty soon nothing is from any
consistent source and your system is a mess.
I guess what I don't understand (taking your
example) is:
1) why should a package from freshrpms update the
mplayer libs if I already have current versions
installed?
2) Even if it does (because the release number in
mplayer-version-release is higher), why will those
versions break the livna mplayer?
I.e, I am having trouble with the meaning of your
word "consistent".
Its all about naming conventions and versioning numbering schemes.
Examine the complete names of any given rpm:
Here is one example:
zip-2.31-1.2.1.x86_64.rpm
Ok, the package name is zip. How do I know? Well it looks like the
first thing after the first '-' dash character is a version number.
So look at the version number. What constitutes the version number?
The only way to know for sure what the packager used as the version
number is to ask the package:
/bin/rpm -qp zip-2.31-1.2.1.x86_64.rpm --qf '%{version}'
returns: 2.31
So what does the rest of it mean?
Here is the specified (by RH) formula for package names:
'%{name}-%{version}-%{release}.%{arch}.rpm\n'
You can see this in: /etc/cron.daily/rpm
Notice the placement of the dashes and dots.
Consider the sorting order of the two text strings: FC5 and fc5
Now look at another package name:
yum-2.6.1-0.fc5.noarch.rpm
Notice the fc5 in there?
OK, one more item to consider for this discussion.
Who decided that kernel modules should start with the text 'kmod' ?
Now you have enough information to understand the basics of the problems
that package maintainers have with just the package naming scheme. Let
alone issues to do with the contents of packages, such as file
locations, menu locations, and permissions.
All it takes is for one maintainer at one repository to not get the memo
about FC5 vs fc5 and BOOM. Those packages now all want to be updated
even though they shouldn't be.
What if a maintainer fumble fingers a version name? BOOM all updates
may actually DOWNREV.
These are just some silly examples, but both of these do happen, and
have happened.
By mixing repositories you risk:
1. Package naming schemes causing false or bad updates and partial
updates.
2. Package dependency errors because one package maintainer specified
different dependencies than another.
3. Library errors because one package maintainer had different
versions of dependencies installed when the package was built.
And the list goes on.
Please understand that these guys try their best. But sometimes
decisions are made that everyone didn't hear about in time, or
whatever. Stuff happens.
The end result is that one day you try: yum update whatever -- and the
dependencies just won't resolve no matter what you do. So you will have
to start removing packages to get something to install or update
correctly. Its a pain. Its also something that a more casual user just
cannot do.
