Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

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

Jeremy Blosser wrote:
> On May 15, Daniel Goller [dgoller AT satx.rr.com] wrote:
>>  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
> 
> It depends on the type of patches.  For stuff we're applying to make things
> build or apply security updates, we're always going to apply them and just
> need to do them in the right order so we don't have unexpected conflicts.
> 
> In the case of optional feature patches the users may or may not apply,
> having simple ordering is more complex since the actual content of the
> patch may vary based on what other patches were or were not applied first.
> 
> I know I started out with sequence numbers for the mutt patches and dropped
> them for this and other reasons... I think the main reason was it becomes a
> pain to keep renaming patches all the time because new ones are added or
> removed.  You can avoid this with a sufficiently large number of digits but
> I think what mutt ended up with is a good bit simpler while still
> accounting for the various use cases.
> 
> But again, it depends on which kind of patches we're talking about.
> Feature patches and bug/security patches are really not the same thing.
> 

Automation would be neat, but we'd have to have an application file or
something. Like a file that specifies the order in which patches get
applied.

It's getting somewhat complicated, but it could be done, and with a well
thought out API, optional patches could be programmed in. (Like a
PATCHES file that uses the patches in the patches dir or somethin)

apply_patch name.patch
apply_patch othername.patch
optional_patch "what the feck does it do?" y ricer.patch

or something like that ;)

Of course, it's adding another layer of complexity which could be done
elsewhere... Depends on the amount of work vs. the amount of benefit.
I'm not really sure it's needed. I've worked with only a few spells that
have patches. On the other hand, however, it might be a good idea to
hash this out now, before it's a big problem. Or it may never become a
big problem.

- --
David Kowis

ISO Team Lead - www.sourcemage.org
SourceMage GNU/Linux

Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
  - Robert Heinlein

Any sufficiently advanced technology is indistinguishable from magic.
  - Arthur C. Clarke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iQGVAwUBRGlQT8nf+vRw63ObAQIktQwAhiq0A8qACiLTCySCicWDgjbBeKJHahXz
uvs5IQz/OWS2vJhdWXDSo6EL/E7X/Rzxjh2T3m649MIl30AZHnMS12trEjkX+Em6
/5MhXuCVYDSnzV772XazPL982HZrXFBU1omV/ZZkr4i/DlOEA1omUZp9L/XorXV3
1cehMgm9UlkI/16HD0odt0fWXA2KUaPOcPPc5Jsnk00NwAX3y3C1z0Hq7tw97cLW
9fe2DAb41xNFnZSOChCPeW/x+KCwPb7iwDBqftoCUM+T6tGE8KIkNUlPAGRByGlL
YRhTiQ7qwnMCxLEea9XDuUKKp9HFzKnAfej6QvHxKkYQpiUHvi5AIpUlr7sixFa7
oIRqoj0+nb3CwqKNnqSU6N7FqLn/BCAsyQQ6Cv/c3ULzv5b9CRb4Oxk35tSsvKIe
E9v5Gl567Cz0YyTfyhYh8/wIyvCaCOg+vg7a8RCeFUInu56ordLkTuQXwjryU2UG
rMxvk9GCyhfmxFDN3stp4btLMavuPqfs
=VdMO
-----END PGP SIGNATURE-----