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

Re: How to handle Debian patches

On Fri, May 16, 2008 at 05:13:24PM -0500, Manoj Srivastava wrote:
> On Fri, 16 May 2008 23:27:03 +0300, George Danchev <danchev@spnet.net> said: 
> > On Friday 16 May 2008, Joey Hess wrote:
> >> Raphael Hertzog wrote:
> >> > I totally agree that we need to make our changes more visible. In
> >> > the openssl case, the patch in question is inside the .diff.gz and
> >> > you don't notice it in the unpacked source package. I tend to give
> >> > a look to what's in debian/patches/ when I rebuild a package but
> >> > not to what's in .diff.gz only.
> >> >
> >> > To me this one proof more than even when VCS are used to maintain
> >> > packages, our source packages must clearly identify the Debian
> >> > patches that are applied.
> >> 
> >> You're insinuatiog that a VCS does not allow easily browsing and
> >> examining patches, and I just don't buy it.
> > This is true, but not always handy. What you might buy is that the
> > upstream or resp. debian user is not supposed to know for your kind of
> > VCS (having it installed, etc) and where to find your VCS repo -- a
>         I find this to be true for quilt too. How does one extract what
>  the 057th patch does, without examining all the leading patches up to
>  that point? Linearizing features and intermixing integration changes
>  along with feature-sets  is something I have always found confusing.
> > ftp'ing of diff.gz or apt-get source pkg should be enough to get the
> > *clearly identified patches* to the upstream source tree.
>         I find a quilt series to not fit the bill very well. On the
>  other hand, creating ./debian/topics/foo/  with a git-format-patch
>  series for each branch in there might be doable -- but then, these
>  individual patches might not apply cleanly over each other.

Having to merge 30 topic branches is not a workable solution either.


Reply to: