Re: Uscan enhancements revitalised (Was: let uscan exclude some upstream files)
Hello. An implementation selecting removed upstream files via a fake license in debian/copyright can be found at [1]. The perl script runs some tests based on the sample/ directory, but the effective code may easily be pasted into uscan if ever accepted. Feel free to experiment, comment and submit other corner case tests. [1] http://wiki.debian.org/UscanEnhancements?action=AttachFiledo=gettarget=select_removed_files_from_copyright_file.tgz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121231181343.GA16686@pegase
Re: Uscan enhancements revitalised (Was: let uscan exclude some upstream files)
On Thu, Dec 20, 2012 at 11:19:19PM +0100, Andreas Tille wrote: As I see on your Wiki page you have described your proposal from your last posting on the mailing list[3] which is actually in contrast to what is implemented in [2] and was described and discussed in the thread starting here[4]. I should most probably add the current implementation to the Wiki page and I will do so in the next couple of days. But before I'm starting to do so I would like to clarify why you used the headline Implementation about the paragraph explaining what is not implemented. That's a bit confusing but may be I missunderstood something. Before I start mixing up things I'd like to hear your real intention which I might have missed. Now for the current implementation: The stumbling block I was currently facing is that I want to strip some upstream source (of igv[5]) from a jar file which resides inside the packaging root as well as in a subdirectory. It looks like IGVDistribution_2.1.30/goby-io-igv.jar (a) IGVDistribution_2.1.30/lib/goby-io-igv.jar (b) The thing is that (a) should be removed and (b) needs to remain - but this case is not possible with the current implementation. If Files-Excluded contains a string without '/' a find -name search is approached and catches them all. I remember this behaviour was mentioned as a design flaw but the pro-argument is that you really comfortably can use this when doing things like Files-Excluded: ._* *~ .DS_Store If you would need to specify each and any dir containing such cruft files this would become a really lousy way which is not better than keeping the old get-orig-source way. I should have documented the Files-Excluded field in the Deleted file specification section. The Implementation section was supposed to collect information for developers, but the name is quite inaccurate. Feel free to modify the page. However, I strongly disagree to interpret patterns differently depending on whether they contain a slash or not, while find -path alone handles your examples. for pattern in IGVDistribution_2.1.30/goby-io-igv.jar ._* */._* *~ .DS_Store */.DS_Store loop `find $main_source_dir -path $main_source_dir/$_ -print0 | xargs -0 rm -rf`; end loop; The objection you've raised in https://lists.debian.org/debian-devel/2012/09/msg00202.html persists, but I consider that sparing a few patterns is not worth the added complexity. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222110611.GA5759@pegase
Uscan enhancements revitalised (Was: let uscan exclude some upstream files)
Hi Nicolas, its a long time since the last posting in this topic - perhaps because everybody was doing bug squashing for Wheezy but recently I needed to rethink the status of my proposed uscan enhancements[2]. On Sat, Sep 22, 2012 at 10:32:12PM +0200, Nicolas Boulenguez wrote: On Mon, Sep 10, 2012 at 09:26:40AM +0200, Andreas Tille wrote: Would you volunteer to create a Wiki page to enable better structure and which might lead to some consensus about the implementation? Anyone interested, feel free to review [1] and continue the discussion there. As I see on your Wiki page you have described your proposal from your last posting on the mailing list[3] which is actually in contrast to what is implemented in [2] and was described and discussed in the thread starting here[4]. I should most probably add the current implementation to the Wiki page and I will do so in the next couple of days. But before I'm starting to do so I would like to clarify why you used the headline Implementation about the paragraph explaining what is not implemented. That's a bit confusing but may be I missunderstood something. Before I start mixing up things I'd like to hear your real intention which I might have missed. Now for the current implementation: The stumbling block I was currently facing is that I want to strip some upstream source (of igv[5]) from a jar file which resides inside the packaging root as well as in a subdirectory. It looks like IGVDistribution_2.1.30/goby-io-igv.jar (a) IGVDistribution_2.1.30/lib/goby-io-igv.jar (b) The thing is that (a) should be removed and (b) needs to remain - but this case is not possible with the current implementation. If Files-Excluded contains a string without '/' a find -name search is approached and catches them all. I remember this behaviour was mentioned as a design flaw but the pro-argument is that you really comfortably can use this when doing things like Files-Excluded: ._* *~ .DS_Store If you would need to specify each and any dir containing such cruft files this would become a really lousy way which is not better than keeping the old get-orig-source way. I / we need to think about this. Kind regards Andreas. [1] http://wiki.debian.org/UscanEnhancements [2] git://git.debian.org/git/users/tille/devscripts.git [3] https://lists.debian.org/debian-devel/2012/09/msg00202.html [4] https://lists.debian.org/debian-devel/2012/08/msg00600.html [5] git://git.debian.org/debian-med/igv.git -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121220221919.gb24...@an3as.eu
