[arch-dev-public] Namcap/XZ compatibility (was: Accept any *.pkg.tar.* package file name)
dpmcgee at gmail.com
Mon Feb 22 00:55:03 EST 2010
On Sun, Feb 21, 2010 at 11:15 PM, Pierre Schmitz <pierre at archlinux.de> wrote:
> Am Montag, 22. Februar 2010 05:33:56 schrieb Dan McGee:
>> >> > Another thing: it was mentionned on the IRC channel that namcap
>> >> > doesn't work with the new xz packages. It would be nice to have xz
>> >> > support in namcap before we start pushing these changes out.
>> >> Yeah, this is IMHO a blocker to going gung-ho on this. It is not going
>> >> to be super-easy either as we use python's built-in archive support
>> >> that doesn't know about XZ as far as I know...
>> > Why not? Just call bsdtar to extract the tar somewhere. This way you
>> > don#t have to worry how the package is compressed.
>> Maybe you can get away with this in a shell script, but no one is
>> happy with this BS in a python program. Or at least I wouldn't be, but
>> feel free to send a patch to the namcap maintainer since it is so
>> easy. I'll be impressed when you fix every check that uses
>> tar.getmembers() too...
> What's wrong with you? That was meant as a serious question. I am not familiar
> with the namcap python code.
Sorry if I came across as snarky, but it drives me crazy when people
make unfeasible suggestions without looking at the completely open
code first. Namcap does a lot more than simply look at an extracted
set of files, a lot of which requires access to the tar metadata. My
point was only to say "this isn't as easy as you make it out to be".
> I don't really want to drop the idea of xz compressed packages just because
> python does not support it.
I'm not advocating that, I can assure you. I am glad Allan came up
with that link showing that XZ support in Python does have some
> It might sound silly but the probably easiest solution might be to modify
> namcap to support uncompressed tar archives. Then we can add a simple Bash
> wrapper script which uncompresses the package and calls namcap with the pure
Looking at the code, there is nothing preventing this right now- we
just use a generic tar interface which will support any compression or
no compression at all.
More information about the arch-dev-public