Re: .changes files as first-class objects
"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> On Fri, 2010-01-15 at 01:48 -0600, Raphael Geissert wrote:
>>> diff --git a/lib/Lab.pm b/lib/Lab.pm
>>> index cc319ce..565d38d 100644
>>> --- a/lib/Lab.pm
>>> +++ b/lib/Lab.pm
>>> @@ -50,6 +50,7 @@ sub is_lab {
>>> return -d "$self->{dir}/binary"
>>> && -d "$self->{dir}/udeb"
>>> && -d "$self->{dir}/source"
>>> + && -d "$self->{dir}/changes"
>>> && -d "$self->{dir}/info";
>>> }
>> Although I understand the reason for this change there's a subtle
>> problem with it: the frontend checks the return status of is_lab() and
>> dies on failure.
>> This would make lintian complain about any existing lab and require
>> either the creation of $labdir/changes by hand or the complete
>> recreation of the lab. Although the latter is pretty much what happens
>> because of the lab version bump, the version change is handled
>> gracefully.
>>
>> So, I think that change should not be made.
> Having is_lab() return success for something that doesn't match the
> current lab format seemed wrong. I'm happy to skip this change if the
> consensus is that it shouldn't be included, as we've bumped the format
> version at the same time.
I unfortunately haven't had a chance to do a full review of this patch
(trying to get to that soon), but the above patch indicates that we're
adding laboratory data for changes files? I'm not sure that's a good
idea.
The main point of writing data to disk, now that we have Lintian::Collect
that could hold it, is because it's very useful to use the lab to look at
various archive-wide things. This doesn't apply to changes files since
one is rarely going to run Lintian on a *.changes file with a persistant
lab. They're not part of the archive under normal circumstances. There
also isn't much interesting data there; anyone who does have a large
collection of *.changes files that they want to review will just grep
through them all.
Given that, my inclination would be to store the *.changes file
information only in memory, which then won't require any change to the lab
format and won't require the additional directory. It does require a new
way to store the data, of course, which doesn't have an unpack script, but
I think we could special-case that to start and then later, if/when we add
*.dsc files as another first-class object, we can generalize.
> Previously the frontend would read the .changes directly and only
> schedule the contained files if the .changes passed basic validation
> (which basically amounted to "has a Format field"). With .changes being
> promoted to checkable objects in their own right, so long as the file
> can be parsed and files found listed in it, they will be scheduled at
> the same time as the .changes file itself.
This sounds reasonable to me, to mention.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: