Re: Closing bugs in removed packages, plus .status format change
On Sun, 23 Mar 2003, Adam Heath wrote:
> On Mon, 24 Mar 2003, Colin Watson wrote:
>
> > I assumed we'd need a new type in debbugs.trace (to go with 'new',
> > 'change', and 'archive'). Looking at it harder, though, that field seems
> > to be purely cosmetic: nothing touches it.
> >
> > Could you please change makeindex.pl to recognize 'unarchive' as well as
> > those three? I'd prefer to keep the operations separate.
>
> Ok, done.
>
> But, when control@bugs unarchives a bug, it will *not* reopen it. That should
> be a separate step. This would need to be documented well, as I would see
> some people thinking that the bug would be automatically reopened.
>
> Btw, I'm working on changing the .status format. There will be a new file,
> .db, that will be formated like a dpkg control file. My plan is to work on
> some converter code offline, modify the existing .status reader, modify the
> existing debbugs code to .....
>
> NOT USE GLOBALS FOR BUG DATA,
>
> and then when all looks good, disable the scripts, convert the files, and
> reenable everything.
adam@yakko:~/debian/new-debbugs$ ./fix-status.pl |head -n 30
Title: mention old and new version with "apt-get -s dist-upgrate" [patch]
Package: apt
Originator: Matthijs Melchior <mmelchior@xs4all.nl>
Date: 986079831
Message-ID: <m14jTlV-00039WC@p2pc.maarssen.nl>
Tags:
pending:
patch:
Done:
Forwarded:
Merged-With:
Severity: wishlist
(this is bug 92358).
Note, that I have changed the order of the fields, to make parsing the files
by humans a tad easier, but the code itself won't care, when reading in the
files.
The output methods support hashes of hashes of lists of lists, so, in theory,
parsing should be rather easy.
-rw-rw-r-- 1 adam adam 182 Jan 12 14:49 spool/db-h/58/92358.status
-rw------- 1 adam adam 277 Mar 24 11:35 spool/db-h/58/92358.db
Since both file sizes are under a cluster/sector/block in length, there won't
be any additional space requirements, after the conversion is finalized.
However, during the transition, the number of additional inodes will increase
by 159000(or so), which is well under master's limits.
Question: Should I store the bug# in the .db file? It would make scripts
easier to write, as you could just cat *all* files together, to build the
in-memory database, instead of having to do each file in a loop, matching up
the filename(and the bug number) with the data.
Reply to: