Re: [jakemsr@clipper.net: Re: lie to apt]
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.
<jakemsr@clipper.net>
Reply to: