Thanks for the info and the suggestions. Seems I was mistaken, I had hoped
cpiobin would help get around
the errors. Although on "(and one would only have to distribute the delta
change rather than *everything*).",
I unfortunately have a large numpy array which is the major cause of the
size, and would change frequently.
[Basically a classifier that changes as training set is updated, I am
looking into using better algorithms and
feature selection to limit the size]. Ideally I would have liked to present
this as a service presented to multiple
destinations, however due to lack of resources available, I am looking for
On Tue, Mar 5, 2013 at 5:16 AM, Jeffrey Johnson <email@example.com> wrote:
> On Mar 5, 2013, at 12:01 AM, ark ph wrote:
> Is this what defines the format of the archive that rpm will use? Can I set
> the path with option to cpio, e.g. from
> http://www.gnu.org/software/cpio/manual/cpio.html if I use cpio
> the maximum size of archive can be 8589934591 bytes? For creating a very
> rpm, cpio limits the size of the archive, would this solve the issue?
> Actually its these two macros that set the payload format:
> # Archive formats to use for source/binary package payloads.
> # "cpio" cpio archive (default)
> # "ustar" tar archive
> #%_source_payload_format cpio
> #%_binary_payload_format cpio
> I'm not at all sure what the "cpiobin" macro is or does: its not in @
> rpm5.org sources.
> Meanwhile its unlikely that you could/would be able to "fix" a cpio
> file/payload limit problem by
> changing a macro or the payload format in any version of rpm.
> [I m building a large package, size is large primarily due to large numpy
> object, and get cpio:bad magic error; as of now cannot
> deploy it as service hence package it with rpm; any suggestions on best
> The best approach is to rethink how you wish to distribute large archives:
> are many performance issues downloading/uncompressing a single _HUGE_
> archive; you are often better off by spitting into smaller packages,
> if some of the content changes less often the rest (and one would only have
> to distribute the delta change rather than *everything*).
> 73 de Jeff
Received on Tue Mar 5 16:22:15 2013