[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: patch filenames
On 07/01/2008, at 15:20, Joerg Sonnenberger wrote:
On Mon, Jan 07, 2008 at 01:50:01PM +0000, Alistair Crooks wrote:
On Mon, Jan 07, 2008 at 01:30:12PM +0100, Joerg Sonnenberger wrote:
On Sun, Jan 06, 2008 at 12:50:44AM +0100, Roland Illig wrote:
3. Group functional changes into one patch file:
Absolutely rejected. This is a nightmare for maintainance.
I disagree, having designed and used a packaging system
which used this infrastructure. It works very well, is
kind to the SCM, and is efficient to the point of brevity.
I regulary have to deal with files that are patched already. Adding
order means that you can't just add the change and diff again, you
to consider whether you should modify one of the existing patch
fragments in which case you have to regen all later patches. We do
have the tools for this.
We *do*. Again, see devel/quilt. Whether you like it or not, that's
I also don't buy the argument that it makes pushing patches upstream
easier. From the long list Roland posted, a lot of them are either
essentially dead (xview) or notorous for not accepting proper patches
for years (mozilla).
Right. So, for example, you have to send a patch upstream that adds
__NetBSD__ checks everywhere alongside some existing __FreeBSD__
ones. These changes affect several files. With the current approach
you have a gazillon of different patch-* files, one for each, that
are not related in any way, when, conceptually, they really are
related because they are fixing the exact same problem in multiple
Then, to make things worse, some of these patches also have other
completely-unrelated stuff in them, say because they are dealing with
the sysconfdir stuff. This also affects multiple files.
Now, how is it easy to send the first set of patches (the __NetBSD__)
ones upstream? It is not. You have to go, mix them in a single
patch, remove all garbage that does not belong there and then send
the resulting file upstream, which at this point has no relation with
the patches in the pkgsrc tree. That becomes very, very boring, and
even more, makes tracking upstream patches very hard because they
have no direct correspondency with the ones in pkgsrc.
Julio M. Merino Vidal <jmerino%ac.upc.edu@localhost>
Main Index |
Thread Index |