Re: New dpkg: --force-overwrite is no longer on by default
>> I believe I've got gettext, automake and autoconf ... what's the
>> problem with lout on m68k
>It segfaults trying to process it's own documentation, I wanted to
>track it down with efence, but that needed a kernel patch and I didn't
>want to ruin my 30 day uptime :-)
:-) Don't bother - if it's that insane it would be a long debug ....
>Don't bother with the non-experimental version, it also requires
>libtool, tetex-*, debiandoc2* (also hosed on m68k, due to a suspected
>compiler bug), sgml*, sp, etc.
Nice to hear. Does that need fixing before the release ??
>> and more important: why does the dpkg build depend on something
>> that's not available for all architectures?
>Well lout *should* be available for all architectures, it's just
>broken on m68k atm. But dpkg _shouldn't_ depend on all this stuff, it
>never use to pre-automake, however when someone decided it would be a
>good plan to automake-ized dpkg they seem to have truly FUBARed the
And as you pointed out above, quite a few other broken things would be
required as well. I just hope the secret knowledge how to build dpkg
doesn't die out by some stupid accident :-)
>I personally haven't got the energy to go and track down the problem
>with the .tar.gz in experimental, and dpkg releases are so infrequent
>I've been even less inclined than usual.
Yep, as long as it's just 'build dpkg once a year' I agree, but I need to
build dpkg to test various strategies for installation off HFS filesystems.
I guess the easiest thing to do would be to rewrite HFS so it won't present
the MacOS specific metadata in readdir() anymore.
>Go to the top level build directory and simply `find . -name
>archtable.h', IIRC there's only one occurrence of each missing file,
>so there should be no particular problems.
My problem wasn't to find what file to copy but where to stick it. I'll try
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com