On Thu, Feb 14, 2008 at 04:43:52PM -0500, Clint Adams wrote: > On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote: > > I suggest to mandate "remove all generated files in the clean target" > > (formulated in a way which includes "generated by upstream", not only > > "generated by the build target), which implies "rebuild everything in > > the build target". > > Tell me how I, as an upstream, can use an experimental version of > libtool in that situation. Upstream can do whatever they want, of course. Policy only applies to Debian. So I'll instead answer the question "How can I, as a packager, follow this rule when upstream uses an experimental version of libtool?" If a package requires a compiler which currently is not in Debian (main), then the package cannot be in main either (even if the compiler is free). This situation you describe falls in that category IMO. A workaround could be to not regenerate the files. This is how it is usually done now. IMO that is incorrect, because the compiler for every generated file must be in Debian. The current practise of not rerunning autotools makes this rule technically unnecessary, but it can still be violated (and that should still be considered a bug, even if it doesn't result in a build failure). Another workaround could be to include the experimental libtool in the package. This is not a very good idea, and it would probably be better to package the new libtool as a separate package (not named "libtool", to avoid it being used as default) and Build-Depend on that. Even better would probably be to convince upstream to not use features of experimental versions. That may of course not always be possible. :-) Does this answer your question? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature