Re: abiword

2016-04-16 Thread Lamar Owen

On 04/16/2016 02:29 AM, Yasha Karant wrote:
I may be in a university environment, but we do not waste time 
reinventing the wheel for research or research support activities -- 
and neither does any other viable research group. 


No insult was intended, incidentally, but you are still in a different 
environment than most of us, myself included.  In my environment I run 
the IT department (and we run an open IT using as much open source as 
possible, with as much user feedback listened to as is practical).  I am 
cognizant that my situation is probably also a bit unique in that I have 
flexibility (and authority in my environment as CIO) that many people on 
this list do not have.


However, it was my understanding that the EPEL or other similar 
automata are not readily available -- for deploying production code 
through porting there is no reason not to use an existing "automaton" 
that can resolve dependencies (I recall a correspondent referring to 
these sorts of things as :dependency hell") from whatever source code 
repositories as required and ultimately build a working executable 
application. 


The full EPEL build system is open source; it's called koji and is what 
the Fedora Project uses to build packages.  You can replicate the full 
Fedora build infrastructure yourself on your own server farm if you 
wished (and had time/resources) to do so.  See the following links:

https://fedoraproject.org/wiki/Infrastructure/KojiBuildSystem
https://fedoraproject.org/wiki/Koji
https://fedoraproject.org/wiki/Koji/ServerHowTo

Your understanding of the availability of the EPEL buildsystem was 
correct only in part; EPEL is built against RHEL packages that are not 
publicly available, but there is nothing preventing you from using the 
koji software to build/rebuild EPEL (Fedora) source packages using 
ScientificLinux packages to populate the buildroot. And, in my opinion, 
EPEL needs to continue to be built using RHEL packages to populate the 
buildroot, as that seems to be the most compatible with the from-source 
rebuilds like SL and CentOS.  But your own, private, Fedora Extra 
Packages for SL is not impossible to do, and all software and processes 
are openly available.


...But -- I would very much like a working SL7 binary executable of a 
reasonably current Abiword.


There are channels to request EPEL packages (especially if the package 
is already in Fedora), and that mechanism has been documented in this 
thread; thanks, Pat!  I chimed in on this thread because I also have 
application for abiword on 7; my particular need has not yet been pressing.


Had the need been pressing I would have built my own abiword packages 
(following the process Russ did and recursively building the 
dependencies) and gone about my merry way without commenting on the 
list. and, in fact, I have done that with other packages in the past 
that I have needed; I have a number of packages that I have built myself 
because no repo had the particular version I needed (a slightly older 
kicad, for instance).


But I am not in the business of being a repo, either; there are definite 
ramifications for binary distribution, and I have no desire to be 
'responsible' again for a widely distributed binary package, outside of 
an established repository, and I would have to have a pressing need to 
do that.  As an explanation for that, I would just point you to the 
following archived mailing list messages: 
http://www.postgresql.org/message-id/200410251354.53583.j...@agliodbs.com http://www.postgresql.org/message-id/200410251334.36550.lo...@pari.edu


Since it appears EPEL7 will have abiword reasonably soon, I'm not going 
to duplicate the effort for my own non-pressing need, but I will thank 
Russ for poking the process along.


Re: abiword

2016-04-16 Thread Yasha Karant

On 04/15/2016 12:54 PM, Lamar Owen wrote:

On 04/15/2016 11:48 AM, R P Herrold wrote:
as well as a well documented, and solved problem with the buildsystem 
which EPEL uses (I was perhaps too eliptical yesterday), and thus my 
dis-interest in re-inventing or re-documenting this wheel ** yet 
again ** -- Russ herrold 


Thanks for working on this, Russ.  While reinventing the wheel is 
frowned upon most of the time, there are settings where reinventing 
wheels should be encouraged, particularly the educational setting. 
Sometimes it is worthwhile to do some calculations by hand or by slide 
rule, then go back to the calculators and spreadsheets; the act of 
reinventing enhances the understanding of why things are done the way 
that they are done. You better appreciate koji if you build your own 
mini-beehive.


For most of us, though, it's just a time sink.  Yasha is in a 
different environment than most of us.
I may be in a university environment, but we do not waste time 
reinventing the wheel for research or research support activities -- and 
neither does any other viable research group.  However, it was my 
understanding that the EPEL or other similar automata are not readily 
available -- for deploying production code through porting there is no 
reason not to use an existing "automaton" that can resolve dependencies 
(I recall a correspondent referring to these sorts of things as 
:dependency hell") from whatever source code repositories as required 
and ultimately build a working executable application.   At the moment, 
my group does not have a porting machine that we could dedicate to this 
sort of problem.  This is not an issue of "critical thinking", etc., but 
rather pure technological implementation.  However, the development of 
that technology does require a variety of "critical thinking" 
activities.  I definitely do not want to get into the repo "business" at 
this time -- we do not have the resources that we can spare from other 
activities, and are not likely to get the necessary external funding to 
become a repo development "house".  But -- I would very much like a 
working SL7 binary executable of a reasonably current Abiword.


Yasha Karant