Steve wrote:
>
>>> insinto "${DSPAM_CONFDIR}" newins
>>> src/tools.pgsql_drv/pgsql_objects.sql pgsql_objects.sql && +
>>> newins src/tools.pgsql_drv/purge-pe.sql pgsql_pe-purge.sql &&
>>>
>> This file is dead in the beta4 and git source.
>>
> Nope. It's right that is not packaged in BETA4 but it's wrong
> regarding GIT. The file is there and will be again included in newer
> versions.
>
Hm, I missed git then. I'll change the ebuild:)
>> 'My ebuild' is based upon the one in a sf bug [1] which is
>> obviously based on he work on portage, which again is yours. IMHO
>> the ebuild is far too complicated to maintain properly,
>>
> It's not that complicated. The whole pre-install configuration is
> pretty logical. The post-install configuration is storage dependent
> but the flow of the script is logical.
>
I've written some ebuilds and my share of shell scripts, and I disagree
with you :) But I think this is more matter of taste, and ultimately a
decision of the person maintaining it. And if we need someone to
maintain it in portage, make it as easy as possible to him (or her).
>> IMHO the auto-configure stuff (emerge --config and various sed
>> stuff during src_install()) should be removed from the ebuild. It
>> would be a lot more useful when it is pulled out of the ebuild and
>> into a separate script, that can be distributed with dspam
>> (dspam-setup?). In stead of relying on USE flags as input for which
>> backends to support, the script could be adapted during 'make',
>> based on configure options.
>>
> I wanted to make one that uses GNU dialog to ask some questions and
> then based on the responses do the whole setup/installation. But so
> far I had not time to do that. But I think that something like that
> could be beneficial to all DSPAM users. Unfortunately not much people
> invest time in helping driving DSPAM ahead. There are many places
> users could help beside developing on the core of DSPAM. I wounder
> why no one is doing small but important things like that?
>
I'm no good with C or dialog, but I can give it a try in shell, similar
to the ebuild. I have your script as a guide.
>> Maybe we can take the gentoo-specific talk off-list and try to get
>> something out that we can propose to gentoo devs for portage
>> inclusion. It would be nice to have beta4 as ~arch or ~arch-masked
>> in portage.
>>
> Alin Năstac is probably loaded with work. Maybe if we move to RC then
> he could include a Ebuild? I think if you would post an Ebuild in
> g.b.o then he would add it to Portage? Should I do it?
>
It seems that your connections are better than mine, so go ahead.
As said, I'll send you some more ebuild-related stuff off-list.
--
Regards,
Tom
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
