[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: