Bug#644019: reglookup: Please package latest upstream (1.0.1)
tim-debian at sentinelchicken.org
Sat Jun 6 02:52:37 UTC 2015
> I don't have a good reference either, but I just found this:
> At least it gives you the command line to use to define the SONAME
> of the library.
> You want your library to have a SONAME of libregfi.so.1 installed in a
> file of the same name (or with more digits: libregfi.so.1.0.0).
> libregfi.so is a development symlink pointing to the current version of
> the library (the one to use when you link with gcc -lregfi).
> You can also read the Debian policy about libraries:
Ok, still on my TODO list.
> Hum, this was not in the 1.0.1 release. We tend to work with what's
> officially released.
> We'll take a look at the trunk...
I agree it is best to stick with releases when you can. In this case,
right after my last release I had a maintainer from another distro ask
for the DESTDIR support and after adding it they were satisfied with
trunk. I didn't bother making another release just for that. Before
I knew it, 4 years had passed and yeah, it's still only in trunk.
Once we get the pieces in place you need for a debian package, I'll
make another release and then you can track releases again.
Another wrinkle: Google is shutting down Google Code, which is a
bummer. I need to migrate my SVN mirror to someplace else. Probably
github, along with the rest of the uncouth masses. I'll let you know
when I do, so you can start working from that.
> For multiarch support we install libraries in different path, for autoconf
> packages, debhelper automatically feeds appropriate parameters. debhelper
> doesn't support SCons because there's no standard parameters or target to
> Anyway, LIBDIR should be enough for our cases, we then have to setup
> this variable to point to an architecture specific path.
> /usr/lib/x86_64-linux-gnu for amd64, /usr/lib/i386-linux-gnu for i386 and
> so on.
Ok, so I think I already have LIBDIR support as well. Just added
CFLAGS and LDFLAGS to a local version. It is possible that some of
the flags I have in each of these by default could cause you problems
on other architectures, but I suppose we'll just have to deal with
those as they pop up.
> > > And also some things which could be improved:
> > >
> > > * please rename "pyregfi-distutils.py" to "setup.py" so that it can be
> > > automatically detected by our build tools
> > Ok, I'll look into this.
> That way we can rely on python packaging tools directly, but in that case,
> it would be nice if we could disable the python part done by scons itself
Ok, that makes sense. Right now the python library installation is
all lumped in with the "install" target. You could build binaries
without interference, but once you tried to install just certain
pieces, the python wrappers will always install, which is probably not
what you want.
Would it make sense to create sub-targets, say "install_python",
"install_lib", etc so that you can call the appropriate one depending
on which sub-package you're building? Or would you suggest another
> No, fakeroot lets you believe that you are root. But a good work-around is
> to not call ldconfig at all when DESTDIR is non-empty.
> $ fakeroot python
> Python 2.7.10 (default, May 26 2015, 13:10:44)
> [GCC 4.9.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> os.getuid()
I was aware of fakeroot, but I must have assumed a while back that
fakeroot wouldn't be that tricky. I've added a DESTDIR check as well
as you suggest.
> Possibly this:
> There's no standard environment variable for installation directories
> AFAIK. Only DESTDIR is sort of standardized...
> BTW, the sample recipe linked from the guide can be found here:
> (since the URL is currently down).
Thank you for the links. I'll look into more of this later to ensure
I haven't missed anything. As it stands, LIBDIR, BINDIR, MANDIR,
INCLUDEDIR, and PREFIX are all already accepted from the environment.
Am I using them correctly? Who knows! ;-)
More information about the forensics-devel