Control: severi -1 minor
Control: tags -1 upstream
Andreas Henriksson writes ("Bug#915955: vm: may embed undesired paths when
built in local environment"):
> The alternative I'd suggest you look at would be if the Makefile
> you ship is useful to include in the package. (I have no idea
> how emacs plugins works.)
Let me start here.
Emacs likes plugins to be byte-compiled because that's much faster.
The bytecode is not compatible between various emacs versions and
forks. So on Debian, Emacs plugins are byte-compiled on installation.
Often this can be done quite simply but vm is an old and complicated
package. The upstream Makefile is what knows how to byte compile it,
and it expects to do interesting things.
So the solution chosen in the Debian package is to ship the upstream
Makefile into the package, and run it at install time (from the Debian
emacsen-common hook machinery, which is what initiates byte
compilation).
> On Sat, Dec 08, 2018 at 09:00:53PM +0000, Ian Jackson wrote:
> [...]
> > I'm sorry to say that while I think that this would be nice to fix in
> > principle, I really don't like your patch. I don't think the appraoch
> > you suggest is a good one in general.
>
> It is the documented autotools solution, so basically what you're
> saying is that you don't like autotools. I'm not a big fan of it myself
> so won't argue with you on that.
I am saying that this autotools behaviour is wrong for Debian.
> My impression is that autotools was designed in an era where proprietary
> unix systems was the norm and you could not expect system tools like
> grep, sed, awk to behave sanely. You thus had to try to find (and
> hardcode in your binary) the path to the alternative gnu version of the
> tool.
Yes.
> I don't think legacy unix systems are relevant anymore, but
> ofcourse different upstream projects has different targets they want to
> support. (The vm indirection of ls and rm makes me curious though, where
> there really systems where these could not be expected to behave
> sanely or why was this indirection added in the first place?)
It is not necessary to decide that those legacy unix systems are
irrelevant. It would be sufficient to observe that this behaviour is
not useful *when autotools is invoked in a Debian package build* and
that therefore there should be a way to avoid it.
I'm sorry to say that I don't have any effort available for tackling
this in autoconf.
> OTOH, vm do declare a dependency on 'make' so maybe the file is shipped
> for a good reason. Maybe you instead need to convince your upstream to
> remove the indirection used in the Makefile(.in). (Patch attached.)
I don't know what upstream's response to that would be. Please do go
and suggest it to them.
I'm afraid I won't be applying this patch in the Debian package.
Things are already confusing enough in this package's build system.
Sorry,
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
