Damyan Ivanov <d...@debian.org> writes:
>
> Creating artificial Contents files as suggested in another mail may
> work (the fiile name shall match some line in sources.list),
That's what I did, program below. (I didn't post because the other
times I posted a workaround the next dh-make-perl invalidated it!)
> I guess it takes quite a bit of time
About 30-40 seconds for me, which is a bit disappointing. It's not much
more than catting together list files, so it should be fast. I assume
it's a combination of dpkg's normal slowness and memory hunger, and just
the data size involved.
> and one has to remember to do it after installinng a locally-created
> package;
Yes. I never tried to automate it.
> * if there are still unfound dependencies, walk over all
> /var/lib/dpkg/info/*.list files (if an option is given, off by
> default) -- or even just call dpkg -S?
How about building a ~/.dh-make-per/dpkg.cache file in the style of
what's done for the contents file. It could be freshened when
/var/lib/dpkg/status changes. And never built at all if apt-file always
answers all deps already. If building is a touch slow then maybe it
could be rebuilt only if the old cached one doesn't answer the deps
either.
I wouldn't worry about dlocate; go either dpkg -S or look at the .list
files directly. (I imagine otherwise you'd have to freshen the dlocate
database after each package install.) dpkg -S is slow, but it's
authoritative, and may be ok if a dpkg.cache rebuild was kind of a last
resort.
gregor herrmann <gre...@debian.org> writes:
>
> The last two steps look like legitimate "add-on-features", and I
> think that "off by default" is important, so that dh-make-perl in its
> default settings works with packages that are in Debian proper.
I'd suggest dh-make-perl should try its hardest by default. If you've
asked for --requiredeps then I think you want it to make best efforts.
For ordinary users local packages will be normal, it's only developers
who get spoilt by putting their deps straight into the archive :-).
One possible option would be whether to prefer local packages over
archive packages. If installing some newer dual-lifed modules there
could be a choice between "perl-modules" or a local package. But I
wouldn't bother with that initially.
#!/bin/sh
# Usage: apt-file-update-installed
#
# Do a fake "apt-file update" which doesn't download anything but instead
# builds a Contents file just from your locally installed packages, as
# reported by "dpkg -S".
#
source=mirror.optus.net_debian_dists_unstable
arch=`dpkg --print-architecture`;
outname="/var/cache/apt/apt-file/${source}_Contents-$arch.gz"
echo "generating $outname"
tempfile=`mktemp /tmp/apt-file-update-installed.XXXXXX` || exit 1
chmod 644 $tempfile
# trap 'rm -f "$tempfile"' 0
(echo "FILE LOCATION";
dpkg --search '*' \
| sed -n -e 's/, /,/g' \
-e 's%^\([^ :]*\): /\(.*\)%\2 \1%p' ) \
| gzip -1 - >>$tempfile
mv $tempfile $outname
ls -l $outname
exit 0
