[luv-main] faking a debian package
I want to install libvirt-bin under Debian, but it depends on libxenstore3.0 and I don't want it installed because I already have xen installed (built from source) and installing the debian version breaks it. What are my options? I can think of: 1. rebuild the libvirt-bin and remove the dependency (easy enough, but the next upgrade of libvirt-bin will break it) 2. force package installation (not even sure I can do this anymore) 3. create a dummy libxenstore3.0 package with a high enough version that nothing can ever upgrade it 4. install libxenstore3.0 but somehow redirect the files (?) Any other suggestions? Thanks James
On Tue, Oct 04, 2011 at 10:07:43PM +1100, James Harper wrote:
I want to install libvirt-bin under Debian, but it depends on libxenstore3.0 and I don't want it installed because I already have xen installed (built from source) and installing the debian version breaks it.
BTW, what exactly is xenstore-utils? i just filed a bug against the package yesterday (Bug#644125) because the package description is useless (all it says is "This package contains the Xenstore utilities." - well, duh!)
What are my options? I can think of:
1. rebuild the libvirt-bin and remove the dependency (easy enough, but the next upgrade of libvirt-bin will break it)
that's why 3. below is the usual method.
2. force package installation (not even sure I can do this anymore)
you can, but it's almost always a really bad idea.
3. create a dummy libxenstore3.0 package
that's the usual way of doing it. there was (or still is) a package that would auto-generate dummy packages for this purpose. can't remember what it was called (i thought it was called dummy or something like that), and can't find it with apt-cache search. OTOH, it's trivial to make a dummy package so you don't really need a special tool for the job. if you want an example, just download the source for one of the transition packages, and modify to suit - they're just dummy packages for when a package gets renamed, they just satisfy dependancies during the transition (and, optionally, depend upon the new renamed pkgs).
with a high enough version that nothing can ever upgrade it
be careful of this, some pkgs depend on package foo version >= x and <= y. probably simpler to just hold the package (with dpkg-hold, aptitude hold, or whatever your favourite pkg holding tool is). Finally, there's also: 4. make your own xen packages from source (maybe patch/update the debianised ones?) so you don't end up with unmanaged cruft in /usr/local or /opt or wherever. craig -- craig sanders <cas@taz.net.au> BOFH excuse #52: Smell from unhygienic janitorial staff wrecked the tape heads
Quoting Craig Sanders (cas@taz.net.au):
that's the usual way of doing it. there was (or still is) a package that would auto-generate dummy packages for this purpose. can't remember what it was called (i thought it was called dummy or something like that), and can't find it with apt-cache search.
'equivs' will certainly do it. http://wiki.debian.org/CreateDummyPackage -- Cheers, "Never bury the lede. Cremation is the Rick Moen only way to make sure it's really dead." rick@linuxmafia. -- FakeAPStyleBook com McQ! (4x80)
On Tue, Oct 04, 2011 at 10:07:43PM +1100, James Harper wrote:
I want to install libvirt-bin under Debian, but it depends on libxenstore3.0 and I don't want it installed because I already have xen installed (built from source) and installing the debian version breaks it.
BTW, what exactly is xenstore-utils? i just filed a bug against the
package
yesterday (Bug#644125) because the package description is useless (all it says is "This package contains the Xenstore utilities." - well, duh!)
Utilities for accessing the xenstore. If you don't know what the xenstore is then you don't need to know what the xenstore is :)
3. create a dummy libxenstore3.0 package
that's the usual way of doing it. there was (or still is) a package that would auto-generate dummy packages for this purpose. can't remember what it was called (i thought it was called dummy or something like that), and can't find it with apt-cache search.
OTOH, it's trivial to make a dummy package so you don't really need a special tool for the job. if you want an example, just download the source for one of the transition packages, and modify to suit - they're just dummy packages for when a package gets renamed, they just satisfy dependancies during the transition (and, optionally, depend upon the new renamed pkgs).
with a high enough version that nothing can ever upgrade it
be careful of this, some pkgs depend on package foo version >= x and <= y.
probably simpler to just hold the package (with dpkg-hold, aptitude hold, or whatever your favourite pkg holding tool is).
Finally, there's also:
4. make your own xen packages from source (maybe patch/update the debianised ones?) so you don't end up with unmanaged cruft in /usr/local or /opt or wherever.
I'm following git/hg fairly closely here and maintaining my own patches so packaging just adds overhead I don't want at the moment. I went with: 5. use dpkg-divert to divert the files I don't want somewhere else. libxenstore only contains the libs (+ stuff in /usr/share/doc) so it should be fine. So far so good! Thanks James
On Tue, Oct 04, 2011 at 11:17:41PM +1100, James Harper wrote:
BTW, what exactly is xenstore-utils? [...]
Utilities for accessing the xenstore. If you don't know what the xenstore is then you don't need to know what the xenstore is :)
the first rule of xenstore is don't talk about xenstore? I inherited two xen servers a while back, one running 5.0.0 and one running 5.6.0. they're considered legacy servers and the VMs on them will eventually be migrated to either KVM (my preference) or VMWare (the uni's standard). several of the VMs are/were running debian etch. I've upgraded a few of them to squeeze, and the guest utilities no longer work (i.e. the xen server doesn't know what OS/version they're running any more, and has no stats on memory etc usage). i've download the latest xe-guest-utilities package i could find (5.6.0-595) but that hasn't helped. i'm kind of guessing that xenstore might have something to do with that....but google has not provided any useful detail on what xenstore is, or whether it's for use on guests or the xen server. craig -- craig sanders <cas@taz.net.au> BOFH excuse #386: The Internet is being scanned for viruses.
On Tue, Oct 04, 2011 at 11:17:41PM +1100, James Harper wrote:
BTW, what exactly is xenstore-utils? [...]
Utilities for accessing the xenstore. If you don't know what the xenstore is then you don't need to know what the xenstore is :)
the first rule of xenstore is don't talk about xenstore?
Xenstore is a key/value tree that stores information about the Domains. The xenstore service runs in Dom0 and the DomU's access it via the xenbus communications inter-domain ring. If xenstore isn't working then xend won't start and nothing much will work. xenstore-ls will dump the entire tree if you want to have a look at the sorts of things that are stored there. James
On 04/10/11 23:17, James Harper wrote:
Utilities for accessing the xenstore. If you don't know what the xenstore is then you don't need to know what the xenstore is :)
The first rule of Xenstore is... :-) -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
participants (4)
-
Chris Samuel -
Craig Sanders -
James Harper -
Rick Moen