Hey guys,

Currently I am converting my work's infrastructure to deb-based packaging. Our intent in the project is to have reproducable releases of our changes to our infrastructure, be it appliction code, a supporting mysql/apache version, etc.

I am building a config package for the Debian-maintained "mysql-server-5.0", using preseed/debconf values to fill in configs on install. The config package PreDepends on a specific version of "mysql-server-5.0" so that we lock the exact version of mysql. The PreDepends line I used in my control file was:

"Pre-Depends: mysql-server-5.0 (=5.0.51a-24+lenny2+spu1)"

For the first part of my development of this package, everything went fine as the exact version of "mysql-server-5.0" I PreDepended on was the only version in my repository, and I was happy with the result. Once I added debian's security repo to my /etc/apt/sources.list (introducing a more recent version of "mysql-server-5.0"), everything went south and on install of my new config package I get the following error, and it all blows up:

Error from 'sudo apt-get install <my config package>':
"<my config package>: PreDepends: mysql-server-5.0 (= 5.0.51a-24+lenny2+spu1) but 5.0.51a-24+lenny4 is to be installed"
(5.0.51a-24+lenny4 is on the newly added debian-security repo)

So, although my package specifically depends on "5.0.51a-24+lenny2+spu1", apt/dpkg is attempting to pull in "5.0.51a-24+lenny4" from the security repo, which adding the repo introduced. This confused me a lot, and it wasn't what I expected apt/dpkg to do in this case. "not installable" seems wrong to me, as it still can access the package versions it depends on.

Looking for answers, I looked at the dependencies of "mysql-server-5.0 (=5.0.51a-24+lenny4)" itself. What I noticed is mysql-server-5.0 depends on ">=" of several packages versions it requires. For instance, "mysql-server-5.0" depends on version (>=5.0.51a-24+lenny2+spu1) of "mysql-client-5.0", "mysql-common", etc, meaning that it could pull in a more recent version than "5.0.51a-24+lenny2+spu1". Is this the cause of my problems? Is apt thinking that although the version I want "=" what I am looking for, that ">=" is more important? Why does this result in a "not installable" state? I am suprised apt/dpkg can't come up with a resolution here when everything is in reach of it.

One solution I came up with is rebuild the debian-maintained "mysql-server-5.0" with hardcoded versions, although maintaining our own packages isn't something I am terribly interested in doing, and I fear doing something like this will cause other dependency issues down the road. I actually am fine with "mysql-server-5.0" managing it's own dependencies if it is possible.

Is there anything anyone can suggest here? I am fairly confident this is either a bug, or I am just using apt/dpkg incorrectly, or the dependencies in "mysql-server-5.0" are strangely conflicting. I really hope I don't have to manually manage my repo, or maintain my own packages to get around this. Our whole intention with this project is to get updates from Debian, but just heavily test/QA those changes ourselves before they make it to our production system, but maybe we/I am just dreaming and this isn't as easy as it sounds.

Here is my control file for my package:

"Package: mysql-config
Version: 0.01
Section: base
Priority: optional
Architecture: all
Maintainer: Tim
Description: Installs Mysql config
Pre-Depends: mysql-server-5.0 (=5.0.51a-24+lenny2+spu1)
Depends: debconf-utils, mytop, rsync
"

I can gladly provide any more details necessary and greatly appreciate any help, suggestions, sharing of experiences, etc.

Cheers,

Tim

Is there a reason why you can't use later versions of the mysql-server package? If it isn't, why not allow the later version to be installed as it probably fixes some security issues. If it has to be that specific version, consider pinning to have your version take precedence over the new Debian package.

Can you elaborate on what you meant here ^^^ on your last sentence? That sounds useful, but I am not sure if I understand you. Currently I am pinning my version like this:

"Pre-Depends: mysql-server-5.0 (=5.0.51a-24+lenny2+spu1)"

As far as newer versions, eventually all security updates will make it to production as they're always important updates, but we want to test each of them with our application in a testbed, ensuring it deploys properly, performs properly, and is expected and controlled.

Essentially, if release 2.00 breaks, we want to be able to go back to release 1.00, including the supporting software (exact mysql-server-5.0 version, etc) from that version as it often has a large effect on our application.

Cheers,

Tim

To better illustrate my point, and my package dependencies, here is a "debtree" diagraph:

http://elementhost.com/tmp/mysql-con...on.debtree.png

"mysql-configuration" and "postfix-configuration" are config packages I created which PreDepend on the server/daemon they're configuring. I chose to PreDepend so that the base configs those servers provide can be moved out of the way on install of my config, preserving the base configs for uninstall, etc.

Cheers!

Tim

I'm sure you are aware of this page: http://www.debian.org/doc/manuals/de.../index.en.html

Pinning is the method used by apt to tell it which repo has priority over others. Found with Google in 0.17 seconds: http://jaqque.sbih.org/kplug/apt-pinning.html was the first hit of over 1.5 million for "apt pinning"

As for the "Pre-Depend" method, it's not really pinning. You are prescribing a particular version to be installed, as a pre-requisite. If you haven't read the first link I gave you, you'll find it very useful

1 members found this post helpful.

Ahhh interesting. I am using incorrect terminology then, cause for some reason I thought 'pinning' referred to specific versions, but clearly I am mistaken. This sounds like it might be what I am looking for.

Thanks a lot!

Tim

Dutch Master, you're right. Thanks again.

Apt-pinning pulled it off, and things looks swell now. I set Debian security to the lowest priority of my 3 repos and that has resolved it. Setting security to lowest sounds strange, but in this case is what is needed seeing my config package from my own repo is determining what should upgrade, and not Debian Security. It all makes sense in hindsight, of course.

Cheers,

Tim

You're welcome Would you mark your original post as "solved"? That way other contributors won't have to read the entire thread to find you have an answer and others who may have a similar problem know where to look for their answer