Re: zip dependency for riscpc install archive
Philip Blundell <firstname.lastname@example.org> writes:
> Are we sure that build-time dependencies on non-US programs are unacceptable?
Yes. See policy on packages in main, Section 2.1.2:
In addition, the packages in _main_
* must not require a package outside of _main_ for compilation or
execution (thus, the package must not declare a "Depends",
"Recommends", or "Build-Depends" relationship on a non-_main_
Note that non-US/main is not the same as main.
> Right now the riscpc install just doesn't work at all, which is obviously no
> good. I'm not sure how to fix it yet, but I guess it needs sorting out one
> way or the other in fairly short order.
> The problem is that RISC OS, the RiscPC native operating system, has extra
> metadata associated with each file that determines its type. This isn't
> particularly important for the kernel and ramdisk images, but it's vital for
> the bootloader itself. Repacking the whole archive under Linux means this
> extra information will be lost and the program won't run any more.
Well, maybe we could use the python/zlib stuff -- I don't know if it
support repacking at all.
> Why's it illegal to use programs from non-US for this kind of thing? I don't
> really understand why zip is in non-US in the first place, is that some kind
> of patent issue?
See above. Zip is in non-US/main because it's compiled with crypto options.
> If there's no acceptable way to build a single archive then I guess we have to
> ship the kernel and root image loose, and have the bootloader in a static zip
> file that doesn't get touched during build. That wouldn't be a problem to do;
> it will make things a little more complicated for the user, but not unbearably
Sounds ok to me.
...Adam Di Carlo..<email@example.com>...<URL:http://www.onshored.com/>