Re: libdebctrl Update
Russ:
Thanks for the discussion. You raise some very good points with
respect to future-proofing the library, and I agree that the previous
design idea I had would have been a maintenance nightmare in the
longer term.
Right now I'm going to try to get the library to accept any
combination of operating systems. I'd like it to do some validation on
input though, to make sure users don't accidentally propose anything
impossible. It's trivial for me to have it check that any
architectures given do not result in something insane -- for example,
a case where someone tries to specify: libfoo [i386 !i386] -- which
certainly is not a satisfiable condition.
I think it would be useful if:
a) The library accepted any given architecture; but
b) The library warns when something looks fishy, like:
i) an unsatisfiable condition as discussed above
ii) the architecture isn't in the known list -- more of a, "hey,
you might have typo'd here, or the list I'm using is out of date, so
please file a bug report"
iii) a particular architecture is specified twice
c) The library could clean up such strange things before writing the file
In general, I have tried to write the library so that, if you input
data and try to save it back out, you will get semantically equivalent
data, but that might not be precisely the same. For example if there
are multiple newlines in a file separating paragraphs, it's considered
superfluous and removed from the output (ie, the extra lines are not
preserved). Other things are that hard tabs (\t) characters used as a
prefix are changed to spaces instead. Warnings are outputted for these
to notify the user of what is happening there.
On Fri, Jun 26, 2009 at 12:03 AM, Russ Allbery<rra@debian.org> wrote:
> Butting in just since the list was cc'd....
>
> Jonathan Yu <jonathan.i.yu@gmail.com> writes:
>
>> I have been working on figuring out how to parse architecture stuff.
>> As I discovered from the debian-policy mailing list, not all
>> combinations of operating systems match up with CPU architectures.
>> What this means is that I cannot store architecture information
>> separately from the operating system -- they have to be paired.
>
>> I was thinking about a good way to do this today, and was considering
>> something like a two-dimensional array, where there are architectures
>> as columns and operating systems as rows:
>>
>> i386 amd64
>> Linux X
>> Solaris X X
>>
>> Means that Linux supports i386 only, and Solaris supports both i386
>> and amd64. So this provides some basic validation.
>
> Such pairings are going to change down the road via external actions
> that aren't tracked, so far as I know, by any other package in Debian,
> including Policy and dpkg. dpkg just allows all possible combinations I
> believe (except for the two special-case architectures, which are
> singletons and don't take a qualifying OS), and Policy stays mum on what
> architectures exist.
>
> No one has to inform anyone before creating kfreebsd-ppc64, for
> instance, and starting to build Debian packages for it.
Thanks for this, I think this particular bit of knowledge will save me
lots of time in the long run. I'll make sure my library is able to
handle this without generating too much noise (in the way of warnings
about a confusing arch).
>
> I'm therefore worried that you're going to find that to be a lot of
> maintenance work, and I'm not sure it's going to accomplish that much.
I am still unsure of how useful these features would be in the long
run, but I think they could help make it easier for developers to pick
up small things like a typographic error in the section name. It is
really just an extra layer of protection, sort of like lintian, before
packages are uploaded.
Reply to: