On Fri, May 27, 2011 at 7:27 PM, Luke wrote:
> On Fri, 27 May 2011, Chris Travers wrote:
>
>> database, do we want to treat creating a new company database as a
>> build process or an administrative task for dependency and/or UI
>> reasons?
>
> I would want it to be administrative. Integrated wit
On Fri, 27 May 2011, Adam Thompson wrote:
> Make (1) is already effectively a mandatory dependency due to all the
> perl modules that must currently be installed, and possibly barring
> OpenBSD with the recent work, I don't know of a single distro that
> packages all the deps. (and, of course,
On Fri, 27 May 2011, Erik Huelsmann wrote:
Hi Chris,
On Fri, May 27, 2011 at 6:28 AM, Chris Travers wrote:
Hi all;
I have gone through the patch queue and applied those which are safe
to apply. A few conflicted with more recent changes. In those cases,
I have generally looked at functional
On Fri, 27 May 2011, Chris Travers wrote:
> database, do we want to treat creating a new company database as a
> build process or an administrative task for dependency and/or UI
> reasons?
I would want it to be administrative. Integrated with the codebase.
No company database should be required
On Fri, May 27, 2011 at 4:06 PM, David F. Skoll wrote:
> Exactly.
>
>> I am just hardly convinced this would be safe in practice.
>
> I think it will be very safe except for the readers of this list. :)
>
>> One of the real reasons this question arises is due to the automatic
>> sql generation th
[Disclaimer: I am not intimately familiar with LSMB internals...]
On Fri, 27 May 2011 14:49:40 -0700
Chris Travers wrote:
> What about installing add-ons into a database? Do we care if
> something has changed and a third party add-on accidentally overloads
> a native LSMB defined function?
Wel
On Fri, May 27, 2011 at 2:23 PM, David F. Skoll wrote:
> On Fri, 27 May 2011 14:01:28 -0700
> Chris Travers wrote:
>
> [...]
>
>> In an upgrade you'd want to run all relevant production-safe tests on
>> your database right? Wouldn't that require a test harness?
>
> No, I think you'd want to run
I definitely agree with that. I think I said things to that effect in an email
yesterday, but not so explicitly:
Stop worrying about install scripts, because every distro pkg format will
require major adaptation anyway.
And, as you just pointed out, figuring out how to package a piece of softwar
On Fri, 27 May 2011 16:23:30 -0500
Adam Thompson wrote:
> My point was that effectively, because of the way installs work right
> now, build deps and installed deps are the same thing. If it's
> impossible to install without building something anyway then relying
> on make is presently OK.
Yes,
On Fri, 27 May 2011 14:01:28 -0700
Chris Travers wrote:
[...]
> In an upgrade you'd want to run all relevant production-safe tests on
> your database right? Wouldn't that require a test harness?
No, I think you'd want to run the tests if you are building a
new upgrade release. But in some dis
My point was that effectively, because of the way installs work right now,
build deps and installed deps are the same thing. If it's impossible to
install without building something anyway then relying on make is presently OK.
-Adam
"David F. Skoll" wrote:
>On Fri, 27 May 2011 15:59:57 -050
On Fri, 27 May 2011 15:59:57 -0500
Adam Thompson wrote:
> Make (1) is already effectively a mandatory dependency due to all the
> perl modules that must currently be installed,
It's a build dependency, but should it be a run-time dependency?
I don't think so, at least not in principle.
Regards,
On Fri, May 27, 2011 at 5:18 AM, Chris Bennett
wrote:
> I also agree, I don't want apache2 on my webserver.
> I will only be running it locally.
>
What web server would you prefer to be running?
Best Wishes,
Chris Travers
-
On Fri, May 27, 2011 at 1:43 PM, David F. Skoll wrote:
> On Fri, 27 May 2011 13:07:06 -0700
> Chris Travers wrote:
>
>> Currently there are two approaches to installing databases in Perl.
>> The first (initiate.pl) has officially been moved to add-ons and is a
>> web-based interface for this proc
Make (1) is already effectively a mandatory dependency due to all the perl
modules that must currently be installed, and possibly barring OpenBSD with the
recent work, I don't know of a single distro that packages all the deps.
(and, of course, make is required anyway for OpenBSD ports)
-Adam
C
On Fri, 27 May 2011 13:07:06 -0700
Chris Travers wrote:
> Currently there are two approaches to installing databases in Perl.
> The first (initiate.pl) has officially been moved to add-ons and is a
> web-based interface for this process. I have not personally used it,
> although I have recently
Hi Chris,
On Fri, May 27, 2011 at 6:28 AM, Chris Travers wrote:
> Hi all;
>
> I have gone through the patch queue and applied those which are safe
> to apply. A few conflicted with more recent changes. In those cases,
> I have generally looked at functional differences where I can.
>
> I have a
Currently there are two approaches to installing databases in Perl.
The first (initiate.pl) has officially been moved to add-ons and is a
web-based interface for this process. I have not personally used it,
although I have recently committed a lot of patches against it.
The second approach is the
I don't think there is any question that long-run we want to have all
the installation done entirely in Perl. This is good because it
reduces dependencies and thus the overall complexity of the
installation. In fact Erik has always said to me that this needed to
be ported to Perl if it worked wel
On Tue, May 24, 2011 at 03:03:19PM -0500, Chris Bennett wrote:
>
> Locale::Maketext::Lexicon
Update to version 0.79
> Net::TCLink - I have no way to test this one.
> Config::Std
Added these new ports
> Template::Plugin::Latex
Added this one and its dependencies.
Waiting for approval for all.
I agree that a perl script is way better. Shell scripts are tricky and not all
OS's use the
same shell. OpenBSD defaults to ksh, bash is an add-on.
Perl "just works".
OpenBSD has a lot of things with PostgreSQL set up differently.
If you read my older install stuff at: http://64.85.161.47:8081/
21 matches
Mail list logo
