Re: ... binary RPM question ...

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

 



On Mon, Jun 25, 2007 at 10:23:52PM -0600, Bob Proulx wrote:

> It is always possible to tar up the binary files and use that as a
> source file.  But if that is all that it is doing I don't see the
> utility of it.  For example (a real example from my experience) let's
> say that the compressed tar file of the installed files is 5G.  It
> takes a large amount of disk to store both the original files and the
> tar.gz and the src.rpm file plus the produced binary rpm file.  Using
> an extra 10G to store the tar.gz and the src.rpm on top of the already
> required 10G for the original native files plus binary rpm is a lot of
> overhead.

OK, one other attempt then to explain it and then I really stop ;-):

Normally, when I package binary (proprietary) software, I start with
something I get from the vendor.  Often a tar file with binaries and
an install script, but some vendors produce more horrible things.

When I then get a new version from the vendor, I can compare the
tarball with the previous version (what files are in it, has the
install script been changed, etc.) because I have the old, original
vendor's tarball included in my src.rpm.

If I would have installed the sofware with the install script and
made the rpm without "Source" files, I wouldn't be able to compare
what the vendor provides and I might have big trouble in "porting"
my rpm to the new version.  This is just one example.  I can think
of many more.

I agree that in the case the rpm build is a step in a larger build
process (that is, you're yourself the original vendor of the
proprietary software) things are a bit different.  In that case your
own build process is the controlled way of generating the rpm and
you don't need to regenerate the rpm with stuff from someone else.
I can imagine you then make other decisions.

But in general the (IMHO) GOLDEN RULE (I don't know if this is ever
written down somewhere and maybe someone can rephrase it) is:

  The files in the resulting binary rpm should *all* be generated from
  *only* the Source and Patch files specified in the spec file.

Note that these "Source" files do not need to be sources, they can
also be (tarballs with) binaries.

And generate means: compile (in case of real sources), but it can
also be copy (in case of binary rpm's).

Note that this rule is never completely true: the result is also
dependent on compiler versions, versions of used include files and
libraries, etc., so (unfortunately) it's not perfect.  But at least
it is something.

-- 
--    Jos Vos <jos@xxxxxx>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux