[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: zip dependency for riscpc install archive



Philip Blundell <philb@gnu.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_
          package),

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.

Yup.

> 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 
> so.

Sounds ok to me.

-- 
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>



Reply to: