Re: Fedora 14 Install Script

[Chris Travers <..hidden..>]

On Thu, Aug 11, 2011 at 5:08 AM, Philip Rhoades <..hidden..> wrote:
> Chris,
>
>
> On Wed, 10 Aug 2011 21:23:11 -0700, Chris Travers wrote:
>> On Wed, Aug 10, 2011 at 2:59 PM, Neon <..hidden..> wrote:
>>>> I would be interested in testing it out - I have had other
>>>> things to
>>>> deal with for a while but I want to get back to this
>>>> soon.
>>> I think (as Matt suggested) I'll try to post it on the devel list.
>>>  Will you get it there?
>
>
> Subscribed.
>
>
>>>>  Ideally, it
>>>> would be good if we could package it into an RPM.
>>> True, to a certain extent.  An RPM would allow the dependencies to
>>> get automatically loaded onto the system (through YUM) (except for
>>> those I had to go to CPAN for). And, if maintained, might get packaged
>>> into the distro itself (with all sorts of help making those CPAN
>>> dependancies also get into the distro).
>
>
> The main hassle for me in the past every time I have looked at the
> install is that I have tried to install all the appropriate Perl RPMs so
> that I don't need to do a CPAN install (which is not nice - I want to
> minimise non-RPM installs).  I have always been, eventually,
> unsuccessful and had to fall back to CPAN.

Have you tried something like

If you point yum at the rpm it should install the dependencies.  If it
doesn't please file a bug.

>
>
>> Have you tried the RPM for 1.2.24?  If there are bugs at the
>> installation there we can fix that or tweak the spec file to include
>> anything additional we need to be doing or provide scripts for things
>> that can't go into the rpm installation itself.
>
>
> I haven't but since the one company that I really used v1.2 for no
> longer exists, I am not interested in going back to v1.2 .

Ok
>
>
>>> But I think it would have limited use with a working-out-of-box
>>> LSMB. It was a bit of a hassle getting things right (mostly within
>>> Postgre, not so much with apache or the OS)
>>
>> This is not something we can really do in the rpm for a number of
>> reasons.  The big issue is we want to play nicely with other apps.
>
>
> What do you mean?  Why should creating an RPM be unfriendly? - it
> should be the opposite for other apps . .

The issue here actually is that the amount of Pg installation and
configuration we can do.  I personally think we cannot do much here.
We could provide model pg_hba.conf files for people who are running no
other apps.  For 1.3, I would like to put forth a special "database"
rpm that would install the Pg server, and provide model configuration
files, command line installation tools, etc.  But I don't think we can
safely modify the pg_hba.conf

>
>
>> What I am thinking about for 1.3 is to break things up into two
>> RPM's,
>> one for the db and one for the web app.  This would allow us to
>> install the db server if necessary as well as command-line tools for
>> setting up the db
>
>
> That would suit me - I use PG heavily for other things and would always
> have it already installed.
>
>
>>> It would be nice to edit some config files within LSMB so that we
>>> don't have to worry about getting the right database, or the right
>>> host, or whatever, whenever we set up the datasets and users. It
>>> seemed to me that those things are going to be always unchanged (or at
>>> least default) after they're set up on the user's machine. Being able
>>> to set those from the setup means it's less error-prone during usage
>>> and there's less instructions for the end-user to fiddle with.
>>
>> In 1.3, one lsmb app has to hit one set of host/port.  The users are
>> set up for the most part within the application itself.
>
>
> PG was never really an issue for me . . mostly Perl . .

Ok, so we are talking about different issues.   The RPM for some time
has been designed to be usable with yum so that automatic installation
of perl dependencies is possible.  Those dependencies that are not
otherwise possible to install with yum, we provide.

Best Wishes,
Chris Travers