[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: viennacl



On 07/31/2011 02:08 PM, Bernhard R. Link wrote:
> * Michael Tautschnig <mt@debian.org> [110730 13:29]:
>>>> - auxiliary/converter is shipped as binary, although converter.cpp probably is
>>>>   its source!?
>>>
>>> Yes. What do you propose? Should I remove auxiliary/converter from the
>>> source package? If so, how? Via a patch in debian/patches?
> 
>> I think for all of the above you should speak to upstream about having them
>> removed. I don't quite know about their responsiveness (or willingness to do
>> so), hence for the moment you might want to start out with a repacked tar ball,
>> [...]
> 
> If you repackage anyway, removing those files would be good. But if you
> otherwise do not need to repackage the orig.tar.gz, please try to avoid
> it.
> 
> If the package contains the source for those files, there is no need to
> repackage the source. Repackaging a source means it gets much harder to
> check if it is the original or if anyone tried to insert stuff there.
> 
> Determining if that actually is the source might not be that easy in
> some cases (sometimes only a .cpp might not be enough), but I think it
> is definitely worth it.
> 
> If there is no source missing, just make sure it is not used in the
> debian build, for example by deleting it in debian/rules before doing
> anything else (in most packages just before running configure is a very
> good time).
> 
> 	Bernhard R. Link
> 
> 

So, your recommendation would be to not create a +dfsg version just for
the reason of removing generated files? That's good news for me, because
I found that maintaining a dfsg_clean branch with git-buildpackage is a
bit of a underdocumented PITA, and IMHO completely breaks when using
pristine-tar.

One question remains, though: should I re-generate those files
(generated sources, Doxygen docs and PDF manual) when building the package?

Michael


Reply to: