Otavio Salvador wrote:
David Cantrell <[EMAIL PROTECTED]> writes:
Otavio Salvador wrote:
David Cantrell <[EMAIL PROTECTED]> 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
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
