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

Re: RFS: ruby-pdf-reader



Cédric Boutillier escreveu isso aí:
> Hi!
> 
> On Sun, Sep 11, 2011 at 11:44:10PM +0200, Cédric Boutillier wrote:
> > On Sun, Sep 11, 2011 at 10:38:55AM -0700, Antonio Terceiro wrote:
> > > If you do not ship the files under bin/, there is no reason to patch them at all.
> 
> > You are right, I committed the patch before deciding not to ship the
> > files in bin/. I will revert 6cb66aaa.
> 
> reverted in the repo.
> 
> > > If you have .pc in .gitignore, it is more difficult to known why a
> > > second build is failing. Overriding upstream's .gitignore does not seem
> > > like a good idea, anyway.
> 
> > Putting .pc in .gitignore is something I got from [0]. How does one live
> > otherwise with this uncommitted directory? (there is just one repo in
> > pkg-ruby-extras) with a commited .pc). I thought that having an upstream
> > .gitignore was in fact a bug in upstream release, is it not?
> 
> > [0]  http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/
> 
> I now understand that this item in the reference above has been outdated
> since #591858 was closed, so there is no need to put .pc in .gitignore.
> Anyway, modifying upstream .gitignore is somehow modifying the source
> from outside debian/, which is bad (even if the presence of upstream
> .gitignore is not optimal, but inevitable with tarballs from github).
> 
> Should I use --filter option of git import-orig to filter out upstream
> .gitignore in the future?

I feel there is no single correct answer for this, but I prefer to not
touch anything upstream unless strictly necessary, including .gitignore
files.

> Anyway, I am reverting my change to restore upstream .gitignore.

Good. I've just uploaded the package.

-- 
Antonio Terceiro <terceiro@debian.org>

Attachment: signature.asc
Description: Digital signature


Reply to: