Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by Ismael Luceno (ebb3d4ea0344f74a552a75a2b3f4df78275aa44c)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: Ismael Luceno <ismael.luceno AT gmail.com>
  • Cc: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Ismael Luceno (ebb3d4ea0344f74a552a75a2b3f4df78275aa44c)
  • Date: Mon, 15 Aug 2016 23:43:03 +0200

Am Mon, 15 Aug 2016 15:30:31 -0300
schrieb Ismael Luceno <ismael.luceno AT gmail.com>:

> > 1. Why does `apply_patch_dir nonexisting_dir` not return an error?
>
> Practical matter, to avoid repeating the condition.
>
> Since git doesn't track dirs, after removing the last upstreamed
> patch things break without the test.

Hm. So you want the option of re-adding patches later without changing
PRE_BUILD … and git doesn't allow you to leave the empty dir there …
*shrug*

> Now I notice I forgot adding -l.

One might debate that, but I guess -l makes life a bit easier for
sloppy patch copying.

> I do not like the idea of letting apply_patch_dir's user specify -p
> directly, because it's global to the directory, and so we would still
> need a directory per patch type, which isn't nice.

Well, you need to settle on one way for the dir, yes. But what if you
got a set of semi-official patches that just happen to use -p0? Being able
to use the function just with -p0 added would be nice.

>
> What I've been thinking about is:
>
> We could try to parse a patch's header,

I'm not sure I like hat. It sounds like too much smarts. I like your
idea about automatic sub depends for optional dependencies, but somehow
I think this here might be over-engineering for the cases where we have
to manage a whole set of patches. The norm is a spell without any patch.

If you put all that metadata into the patch, you save some work writing
the PRE_BUILD script, but that also becomes rather opaque (the actual
meaning of transparent in the context of software;-)

> Headers we would want:
> * X-Patch-Strip (default = 1)
> * X-Patch-Label (a shorthand, mandatory for optional patches)
> * X-Patch-Deps (list of shorthands)
> * X-Patch-Conflict (list of shorthands)

I'd rather have such in a declarative-like syntax in the PRE_BUILD … or
a PATCHES file, very much like DEPENDS. Separate data (patches) and
metadata (dependency information). That way, one also could group
patches together for logical features etc. Not sure how the indivudual
labels would work there.

> > (And bonus: I wonder if we really should encourage file names with
> > carriage returns in them.)
>
> It's not encouragement. We don't want things falling apart just
> because someone made a mistake (or the grimoire got corrupted).

Well, perhaps we _do_ like things to fall apart early so that we don't
tolerate such foolery and fix it early on.


Alrighty then,

Thomas

Attachment: pgphQx2iYuXxL.pgp
Description: Digitale Signatur von OpenPGP




Archive powered by MHonArc 2.6.24.

Top of Page