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.
Mike
Reply to: