[parted-devel] Re: Red Hat Parted Package

[David Cantrell]

Otavio Salvador wrote:
> David Cantrell <dcantrell at redhat.com> writes:
> 
>> Otavio Salvador wrote:
>>> David Cantrell <dcantrell at redhat.com> writes:
>>>
>>>> My understanding of Debian's packaging system is that everything is
>>>> put in a debian/ subdirectory in the project source tree.  A single
>>>> diff is generated which contains the contents of the debian/
>>>> subdirectory.  I find patches in this directory and other build
>>>> control files.
>>> Basically yes but it's not a full requirement.
>>>
>>> If we all move to git we can start to use it  to track all our code
>>> patches and those being manage as normal refs on git
>>> itself. Basically, when exporting the source for Red Hat or Debian
>>> package building we would need to make a diff and put it somewhere on
>>> our building system.
>>>
>>> Nowadays, we have debian/patches/* but we could use
>>> debian/patches/debian_specific.patch that would be all those together
>>> and made automatically. That would allow us to share changes since we
>>> would basically cherry-pick from etch other.
>>>
>>> What do you think?
>> I don't fully understand what you're describing here.
>>
>> I can't use the git repository to track patches since I have to use
>> the main RH build system for everything.  It just duplicates work for
>> me and the likelihood of those patches getting out of sync is also a
>> problem (i.e., which tree contains current patches).
>>
>> Because of the way our build system works, it would be much easier for
>> me to expose the patches and spec files for parted RPMs in some other
>> location besides just the source RPM.  Would that be sufficient?
> 
> I mean that you could have a script that get the diff of last released
> parted and your branch and make a patch that will be used by your
> normal build environment.

This only works well if I wanted to have one giant patch against the 
released version of parted.  We don't do that in RPM packages.  I have 
patches that are by feature or bug so that other people can selectively 
pick and choose what they want.

The old Debian way made that hard, but the new Debian way of having 
debian/patches/* works more like what we have.  But since you track that 
patch collection as a big diff against the released version of parted, 
using git is easy.  We go about it from the other direction, so I don't 
think using git is going to work for me to track patches.

I've got some other things I need to tackle today, but later on I'll 
work on a system to expose all of the patches I have for parted packages 
along with spec files.

-- 
David Cantrell
Red Hat / Westford, MA