Public SourceMage Discussion List

[Flavien Bridault <vlaaad AT sourcemage.org>]

Le lundi 15 mai 2006 à 23:08 -0500, David Kowis a écrit :
> -----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 ;)
> 

Why don't we use a mixed approach ? Most of the time sequence numbers
for the patch will be ok. Lot of spells use only one patch, some of them
two or three which can be applied in any order, and very few cause real
problems afaik. In my limited scope (disk, graphics and graphics-libs),
I only know the grub spell as a trouble maker.
This is a waste of time (and space) imho to add an application file each
time. But for the very few annoying spells such as grub, mutt and
others, we could have a PATCHES file as David proposed that will
override the "default_patch" function.
And that would be compliant with the sorcery way of thinking, as we used
to do that for other stages, right ?

> 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-----
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> 
-- 
Flavien Bridault

Disk, Graphics, Graphics-libs sections Guru
Source Mage GNU/Linux - http://www.sourcemage.org

irc: vlaaad
jabber: vlaaad AT amessage.be

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée