I have a client that needs Mono 2.4 and other related components
packaged for various reasons, and for various other reasons needs
_that_ to be packaged with a 1 binary per 1 upstream source package
mapping. I am trying to accomplish this task, but I am failing
something awful. I am hoping that this is the right list to ask about
From what I understand from the dpkg documentation, a package that
wants to do such a thing must Replace and Conflict with the packages
that it is superceding. So I have this new Mono package which builds
just fine into a binary; it Provides all the virtuals the Debian Mono
source package provides, and it Replaces and Conflicts with the 100+
package splits that come from the Mono source package. However, when I
try to install something like "libboo2.0-cil", apt wants to remove my
package and then install (older) packages from the repository.
When I look at libboo2.0-cil's information, it says that it Depends on
libmono-corlib2.0-cil (>= 220.127.116.11) (my package replaces that one, and
the package version is 2.4), and on libmono-system2.0-cil (>= 2.0)
(again, my package replaces that one, and the package version is 2.4).
There are no Recommends or Suggests in libboo2.0-cil, so I don't know
why it wants to remove my package and replace it with what dpkg should
think is an older package; this package (at least I thought) filled
those two dependencies.
What must a package have in its control file in order to effectively
supercede packages in this fashion? From what I gather from the
documentation, it'd seem that what I am doing _should_ work, but
clearly I don't get it.
Emacs is a nice operating system, but I prefer UNIX.
--- Tom Christiansen