Re: RFS: automake-idl
* Olaf Mandel <olaf@mandel.name> [080602 03:40]:
> > * the repeated use of $(CURDIR) where a . or nothing at all would
> > have sufficed is a bit annoying. (especially when done unsafe and
> > unecessarily adding new problems if paths contain spaces).
> Actually, the unprotected use was only in the parts created by dh_make.
> I changed those. Also, I made the strings a bit shorter by using the
> variable $(DESTDIR) instead of $(CURDIR)/debian/foo. But leaving out
> $(CURDIR) completely... I like how it reminds me of where executables
> are and relative to which path I am working. Is it really that bad?
I only said "a bit annoying". '"$(CURDIR)/configure"' is quite more to
parse than './configure'.
> > * having a build-indep and a build-arch (the latter doing nothing)
> > would be nice.
> Added.
Thanks.
> But install still depends on build => build-indep.
It's not like it makes any difference for this package, thus what
install depends on does not matter.
For packages having both build-arch and build-indep doing something
and those being able to be done independently, having different install
targets depending on the different build targets (or no install target
at all and doing the work in binary-*), would be the way to go.
But in this package the only difference in having build-arch and
build-indep is increasing the number of packages supporting those target
thus increasing the chances they will actually be used in some future
and make building other packages faster.
> I didn't
> understand that part of the policy (ch 4.9) very well: Should I make
> build-arch return with exit status 2 or can I just leave it as an empty
> target?
Just an empty target is good. After all, all what you had to build for
arch dependent packages was done by doing nothing.
> > * Copyright information is incomplete. While copyright information
> > of the build files if often forgotten (but better should not be),
Those are still missing. (i.e. files like missing, install-sh, ...)
> > at least automake-idl seems to contain at least a partial fork
> > auf automake (as opposed to be generated or copied by automake).
> > Even if you do not install that stuff, it's copyrights and licenses
> > should be listed.
> For autoconf-orb I agree, the information is missing. I don't want to
> add comments assigning the copyright information to upstream without
> talking to them, first.
>
> On that note: would it even be Ok for me to add such copyright notices
> to the files, copying information from the COPYING file? Or is this not
> valid?
I think it is best to ask the author. COPYING only contains the whole
license and neigther a copyright notice nor a license statement.
Perhaps the COPYING file was just copied there by automake and the
author did not think about it at all.
After all, even FSF distributes their m4 files under a very permissive
license: (from /usr/share/aclocal-1.10/init.m4 on my system)
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
# 2005, 2006 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
> But with automake-idl, where copyright information is present, I made a
> mistake. That package is GPL2, not GPL3 and the copyright holder is the
> FSF, not the upstream author of autoconf-orb! Sorry about that, it has
> been corrected in the newest upload.
Unless Vladimir Panov assigned copyright to FSF, he still is copyright
holder for at least his modifications.
Some more I just saw: The dependencie of autoconf-orb look very strange.
The dependency on automake-idl looks like it should be an Suggests at most.
The version dependency on autoconf I do not understand. After all, even
with this dependency, you cannot be sure an older autoconf is not used with those
files, and none of them seems to include an AC_PREREQ to actually tell to need
a newer version. So where does this version come from?
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
Reply to: