Bernhard R. Link schrieb: > * Olaf Mandel <olaf@mandel.name> [080602 03:40]: -Snipp- >>> * 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, ...) > Hello, as far as I can see, all files in automake-idl contain copyright information. Especially since missing, install-sh etc are not part of automake-idl. It only contains the main executable and these support files: depout2-idl.m4 idldep idlfix idl.am. All of those have a copyright header in the file. >>> [Copyright notices] >> 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. >> I added copyright / license headers to all files after talking to Vladimir Panov (the original author). He prefers a GPL header over the complete public domain header that the FSF uses for their files. >>> 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. -Snipp- > Unless Vladimir Panov assigned copyright to FSF, he still is copyright > holder for at least his modifications. > Vladimir told me he intentionally left the copyright with the FSF for the patched files and assigned it to the FSF for the files he created from scratch. Is it good enough to just be the original author and claim the copyright lies with someone else (like done here) or would a more formal process be needed (IANAL)? > 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. Actually, I think the Depends is right. While a configure file that does not use the AI_* macros still works with Makefiles generated by the normal automake, a configure file that uses these macros relies on automake-idl being of that-and-that version without (at the moment) encoding this in the Makefile. For example, a new version of autoconf-orb could create configure scripts that do not work on Makefiles generated by the old versions of automake-idl. As the Suggests header does not enforce keeping the version updated (I think), it should be Depends. Or what happens in this case: Package: foo (0.0.1); Suggests: bar (>= 0.0.1) foo, bar both in the same Distribution apt-get install foo bar Package: foo (0.0.2); Suggests: bar (>= 0.0.2) only foo (0.0.2) in the Distribution, bar (0.0.2) is delayed apt-get dist-update I don't think that this would do the correct thing of holding back foo until bar (0.0.2) becomes available (untested! Am I right?). Would a combination of Suggests and Conflicts be appropriate for this situation? I think just a Depends is better, though. > 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? I just copied the version I had on my machine in there, which was too harsh. The package simply depends on autoconf without a version, now. New versions uploaded to mentors.debian.net. Here are the differences: * autoconf-orb: ** All files now contain copyright notices ** Relaxed dependency on autoconf * automake-idl: ** usr/bin/automake-idl was using the wrong default for perllibdir Best regards, Olaf -- Olaf Mandel eMail Olaf@Mandel.name
Attachment:
signature.asc
Description: OpenPGP digital signature