SCIENTIFIC-LINUX-USERS Archives

April 2016

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Thu, 14 Apr 2016 12:05:59 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (65 lines)
On 04/14/2016 11:22 AM, R P Herrold wrote:
> On Thu, 14 Apr 2016, Yasha Karant wrote:
>
>>> I don't and haven't 'publish' binaries for a long time now,
>> Although you evidently are not a "repo", are you willing to
>> allow others access to the built RPMs (not SRPMs) needed for
>> an executable install of abiword? The RPMs I have are all
>> 2.x, nothing in 3.x .  Are there any "conflicts" between
>> what is needed by a more recent abiword and the standard
>> install (from SL/CentOS, EPEL, ElRepo repos)?  That is,
>> package M conflicts with whatever during the binary install?
> Long ago and far away, with the pre-cursor product to CentOS
> (cAos), I built and released binaries.  With the turn-down of
> RHL, and the rise of the 'Enterprise' distributions, I spent
> some time considering 'policy' as to releasing sources vs.
> binaries, and concluded that there were obligations to 'stand
> behind' binaries, which did not arise with a simple set of
> related sources.  Unless one is a commercial customer of Owl
> River, binaries are not available ( contrariwise, all binaries
> installed at any customer are backed by availability of
> sources at the site previously indicated, thus satisfying GPL
> and related 'source availability' obligations )
>
> so, thus, my earlier mention of poking EPEL
>
>> I could attempt to put personnel (grad students, undergrads)
>> on the build, but I really do have higher priority work for
>> these persons.  I myself do not have the spare time right
>> now to contribute much to the porting effort of a standard
>> "office enduser" package.
> And wonderfully, in the FOSS ethic, EPEL should solve this for
> all of us with any luck
>
> -- Russ herrold
Although EPEL "should", being like CentOS these days a more-or-less 
"wholly owned
subsidiary" of Red Hat, but the time it is done we may be at RHEL 8.

You indicated that you are willing to release the SRPMs that have 
already been ported (both for source
code and dependencies) to SL 7 and that upon using a command syntax like:

rpmbuild --rebuild /tmp/mypackage-1.0.0-1.src.rpm

where  .src.rpm is the same as .srpm (as I recall).

will result in a (set) of binary RPM files that will install application 
"binaries" that will execute under SL7.  Any dependencies (e.g., other 
development
packages, not just header file RPMs, but ".so" file RPMs) will be 
revealed by the rpmbuild step and can be "fixed" through
yum install foobar (where foobar is the dependency) from either SL, 
EPEL, or ElRepo, not RPMs for which one has the
merry chase on the web (sometimes resulting in other incompatibilities 
or real vulnerabilities).  I am not trying to be overly specific here, 
but my
group (as I am certain have others on this list) has more than once had 
to chase down RPM dependencies (e.g., libraries) that only were made
at one laboratory somewhere -- and never made it into the "mainstream" 
EL repos (say ported from some other Linux family).

Thanks for any clarification.

Yasha Karant

ATOM RSS1 RSS2