Public SourceMage Discussion List

[Daniel Goller <dgoller AT satx.rr.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

replied wrong again:
Daniel Goller wrote:
> Arwed von Merkatz wrote:
>>> On Mon, May 15, 2006 at 03:38:42PM +0200, Andra~ ruskie Levstik wrote:
>>>> With my recent work on smgb and smbsd I've found that we have a rather
>>>> incosistent way of handling patches so I was doing some brainstorming on 
>>>> the
>>>> issue(with input from others) and this is what I came up with:
>>> I like the general idea, comments below.
>>>
>>>> * a directory patches in the spell dir would hold ALL the patches
>>>> * a format for patch filenames would be defined
>>>>   an example: 001-2-mypatch.diff
>>>>   arbitrary:  SEQ-P-NAME.diff
>>>>   SEQ: sequential number from 000-999
> 
> if they are from 0000 - 9999 you could step 100 for each group, then 10
> within that group and 1 for later additions
> 
>>>>   P: patchlevel
>>>>   NAME: a name for the patch
>>>>   That's for the filename
>>> I wouldn't encode those in the filename, and I wouldn't use sequence
>>> numbers. This is with thoughts about a possible future auto-patching. We
>>> discussed this on irc once, but I don't remember all details, here's
>>> what I do remember:
>>> - all metadata about the patch is encoded in special comments, the
>>>   filename is arbitrary
>>> - instead of sequence numbers, use dependencies to order patches
>>> - define a patch-group field, this is for future autopatching to be able
>>>   to switch patch groups on/off depending on other settings in the spell
>>>
> 
> using sequence numbers would allow us to do autopatching with proper
> ordering while adhering to KISS or the 90/10 rule, cover 90% of the
> cases with 10% effort, while setting something up with dependencies
> might cover the additional 10% of cases it would also require the extra
> 90% of effort
> SMGL does not seem to do a lot of patching, so in reality using sequence
> numbers might cover far more than the hypothetical 90% :)
> 
> using sequence numbers it would be as easy as a for loop over patches/
> in default_pre_build
> 
>>>> * Comments in patches should be defined
>>>>   an example:
>>>>      ***START OF DIFF FILE***
>>>>      ## Description: What does this patch do
>>>>      ## BugUrl: Url to the upstream filed bug about the patch
>>>>      ## Type: [enh|fix|sec|other]
>>>>      THE_PATCH
>>>>      ***END OF DIFF FILE***
>>> Good idea.
>>>
> comments there can be good when going over a spell someone else did
> 
>>>> * If possible ALL patches should be applied in PRE_BUILD
>>> Agreed. There's also the (very unusual) use-case where a patch gets
>>> applied to system-files or something similar, e.g. the firefox
>>> initialization patch that gets applied after install. These patches
>>> should either be left in the main spell dir, or have a metadata setting
>>> defining them as special.
>>>
> 
> sounds like they could be excluded from patches/ as there shouldn't be
> too many of them
> 
> Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaQcL+HaycIPdpbkRAn7lAJ9Fg4+PANARpRXBylJxb4yL6gucQACfZO6I
jsQjob+ZoH3F/rGAkhyvhaE=
=/Neh
-----END PGP SIGNATURE-----