Sat 16 Aug 2003 04:40:07 PM UTC, original submission:
Andrew Suffield <asuffield@debian.org> wrote:
> Here's a cute one. I just discovered the hard way that the regexps you
> define in =tagging-method apply to the contents of the {arch} tree, at
> least in some cases.
>
> I have a project named 'foo', so the category is also named 'foo'. Not
> overly surprisingly, the binary that it compiles into is named 'foo'
> as well. Since this binary can get rather large, I listed it in the
> junk regexp so that it wouldn't get copied around with the
> tree. Unfortunately, that means {arch}/foo/ is no longer copied
> either, so the patch logs keep disappearing whenever I use a command
> which copies a tree (rather than building by patching). This led to
> all kinds of interesting and weird error messages when I first tried
> to update a branch (everything until that point, including the
> creation of the branch, worked fine).
>
> The moral is to use precious instead of junk, unless you're *really
> sure* that the regexp matches something unique. (The solution, if you
> manage to balls-up a tree like this, is to delete everything but the
> archive itself, including any cached revisions and library entries,
> and manually edit =tagging-method inside the base-0 tarball;
> everything is intact, except for the working copies of the tree).
>
> However, it strikes me as odd that =tagging-method affects {arch}. Is
> this a bug?
>
> --
> .''`. ** Debian GNU/Linux ** | Andrew Suffield
> : :' : http://www.debian.org/ | Dept. of Computing,
> `. `' | Imperial College,
> `- -><- | London, UK
"Robert Anderson" <RWA@sbcglobal.net> wrote:
>
> --- Original Message ---
> From: Andrew Suffield <asuffield@debian.org>
> To: -unavailable-
> Subject: [arch-users] Interaction of =tagging-method and {arch}
>
> >However, it strikes me as odd that =3Dtagging-method affects
> {arch}. Is
> >this a bug?
>
> I don't think so. Patches work on {arch} metadata much in the
> same way that they work on your source. So that, for example,
> adding a patch-log is "just another" added file with no special
> casing for the fact that it happens to live under {arch}.
>
> But I think you've hit on something that will not be an uncommon
> problem. I can't think of any situation for which matching
> something under {arch} in a "junk" pattern will lead to desired
> results. So maybe one thing to do would be to add some kind of
> check under tree-lint to guard against this eventuality.
I think this is a bug, since you really shouldn't be able to screw up
the control files with legal commands. It seems like non-default
naming conventions should just be ignored for the control files.
Walter
|