RPM Community Forums

Mailing List Message of <rpm-users>

Re: cpiobin macro

From: ark ph <4rk.p03@gmail.com>
Date: Tue 05 Mar 2013 - 16:16:21 CET
Message-ID: <CAHuJcDf4v=s=QP2N_FCgR0_aKXQHU4q_BxP9OH+FaCHCKF3OdA@mail.gmail.com>
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
packaging it.

On Tue, Mar 5, 2013 at 5:16 AM, Jeffrey Johnson <n3npq@me.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
> --format=tar
>  the maximum size of archive can be 8589934591 bytes? For creating a very
> large
>  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
> array
>  object, and get cpio:bad magic error; as of now cannot
>  deploy it as service hence package it with rpm; any suggestions on best
> approach?]
> The best approach is to rethink how you wish to distribute large archives:
> there
> are many performance issues downloading/uncompressing a single _HUGE_
> archive; you are often better off by spitting into smaller packages,
> particularly
> 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
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.