bugArX revision control system - Bugs: bug #4761, Interaction of =tagging-method and...

 
 

bug #4761: Interaction of =tagging-method and {arch}

Submitted by:  Walter Landry <landry>
Submitted on:  Sat 16 Aug 2003 04:40:07 PM UTC  
 
Severity: 3 - LowItem Group: None
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 25 Aug 2003 04:34:58 AM UTC, comment #1:

Fixed in package-framework--arx--1.0--patch-54. Should be in ArX-1.0pre12.

Walter Landry <landry>
Project Administrator
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

Walter Landry <landry>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Mon 25 Aug 2003 04:37:18 AM UTClandryOpen/ClosedOpen=>(Error - Not Found)
Mon 25 Aug 2003 04:34:57 AM UTClandryStatusNone=>(Error - Not Found)

Back to the top


Powered by Savane 3.1-cleanup1