tech-pkg archive

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

Re: patch filenames




To: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>

Subject: Re: patch filenames

From: "Julio M. Merino Vidal" <jmerino%ac.upc.edu@localhost>

Date: Mon, 7 Jan 2008 15:54:47 +0100


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  have
to consider whether you should modify one of the existing patch
fragments in which cas
e you have to regen all later patches. We do  *not*
have the tools for this.


We *do*. Again, see devel/quilt.
 Whether you like it or not, that's  another story.


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  places.

Then, to m
ake 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>





References:

patch filenames
From: Roland Illig

Re: patch filenames
From: Joerg Sonnenberger

Re: patch filenames
From: Alistair Crooks

Re: patch filenames
From: Joerg Sonnenberger




Prev by Date: Re: patch filenames

Next by Date: Re: patch filenames

Previous by Thread: Re: patch filenames

Next by Thread: Re: patch filenames

Indexes:

reverse Date

reverse Thread

Old Index



Home | Main Index | Thread Index | Old Index