On Thu, Feb 22, 2001 at 02:52:00PM +0100, Arthur Korn wrote: > Hi > > Jacob Meuser schrieb: > > > On Wed, Feb 21, 2001 at 10:13:23AM +0000, Jacob Meuser wrote: > > > > Is there a way to manually edit the database that says which packages > > > > are installed? I set up a small system, using potato, and am adding > > > > several packages from source. I added stuff like glib-1.2.8, tcl-8.32, > > > > tk8.3.2, etc. How can I tell apt that these packages are installed? > > > > Or at least make it think the potato version is installed. > > > Well, that lead me to the files I was looking for: /var/lib/dpkg/* > > Some ideas on how to do this: > > If it's no disc space and bandwith problem for you, you could > just as well install you locally compiled packages in /usr/local > and keep the older packaged versions installed. Dependencies > will be satisfied, and everything should be using the /usr/local > version (there are some search path variables/configuration > settings to assure this, like PATH, > LD_LIBRARY_PATH//etc/ld.so.conf, MANPATH and so on). That's my > prefered way to install (yet) unpackaged software. (Hint: have a > look at 'stow').
I was using stow, so I am familiar with ENV > > In my experience this works much better than trying to > manipulate the status database of dpkg. > Probably so, but it did work. > Another thing to look at is the equivs package, which provides > tools to build empty dummy packages. > Useful, but ah, what is it, a "terrible hack"? > Yet another way would be to grab the source of the debian > packages, upgrade them and build actual debian packages of the > new versions (and send any necessary modifications to the > maintainer of the debian package), though this is probably not > an option for you since it requires quite a lot of experience > with packaging (even more if the debian package uses some > obscure source format or is very old). I well, I won't say anything. > > Sometimes the debian maintainers are not even aware of new > versions of theyer packages (though this usually only happens > with smaller packages), thus dropping a notice pointing to the > new version and politely asking why it isn't packaged could do > the trick as well. > This may be, but more likely, they know the version is there, but are working the kinks out for it to work as a distribution. Maybe I'm greedy, but I want it to work for me and RIGHT NOW! At any rate, I found dh_make, which seems do the trick. One of the main reasons I build from source and don't get packages from unstable, is that I want to keep an eye on "unstable" or exper- imental packages. So I keep them in /usr/local. So I can mount /usr/local separately in case something real bad happens. I just compiled mysql-3.23.33 into mysql-3.23.33-1_i386.deb. It's a bit crude: no preinst/postinst prerm/postrm no init.d, manpage, or menu script. These are the kind of things that take packaging experience, but they are mostly OS/user preference dependent. These are also the things that cause a lag between upstream-release and release of a .deb. Not to mention my mysql package is only one package. I think this would be about 4 release .debs. Not that there's anything wrong with split packages, it can save quite a bit of disk space. tomorrow (today!?) is a busy day. I figure by Sunday, I'll be making good (perhaps not quite release quality) debs. Oh, and I still install my packages into /usr/local. <[EMAIL PROTECTED]>
