-------- Original-Nachricht --------
> Datum: Mon, 09 Nov 2009 22:48:30 +0100
> Von: Tom Hendrikx <t...@whyscream.net>
> An: Steve <steeeeev...@gmx.net>
> CC: dspam-user@lists.sourceforge.net
> Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4
> Steve wrote:
> >>>> '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 :)
> >>
> > Good! I like when people disagree. :)
> > So where and why do you disagree? What can we do better? What can we rip
> out? What can we replace? How can we minimize the code without breaking
> it?
>
> As I mentioned, I think we should rip out all the stuff that tries to do
> the configuration. This holds for both the sed stuff during install, as
> for the post-install script. IMHO we should ship an external utility
> that does all this, and let the ebuild ship the stock configuration file.
>
> The "USE flag to configure options" logic should ideally be the only
> fancy code block in an ebuild. All the rest should ideally be resolved
> 'upstream', f.i. in dspams 'make install'. Since we're upstream,
> submitting a patch upstream is trivial (writing it is something else).
> This would f.i. mean to install helper sql scripts.
>
You miss one point: Everyone and his dog think they can package the product
better. Let's look for example at Debian: They break up the configuration in
peaces and have one part in dspam.conf while having another part some where
external.
And now just think about how many different distros are there and other OS that
do the same. And now try to bring one universal tool helping to configure all
those DSPAM installations. Good look doing that!
It's not easy. Believe it or not.
At the time when I wrote that configure part for the Ebuild, every one in the
Gentoo community was crying out loud how hard it is to configure DSPAM. I could
not hear any more those complains so I did not wanted to repeat the same and
again the same message/instructions on the Gentoo forum. That was one of the
reasons I rewrote the Ebuild.
I do that often. You should see my nginx Ebuild. It's the same here. The
original Ebuild is just plain wrong. But hey... I am to bored to fight with
people in the b.g.o about obvious things. I use the Ebuild for me and I know
that is right (I specifically asked the original author about configure options
and his response confirmed me that the current Ebuild for nginx is not 100%
correct). Today I would probably to the same with the DSPAM Ebuild. I would
rewrite it and NOT submit it to b.g.o.
Don't get me wrong. I love Gentoo but some things are just not the way it
should be. You could now ask yourself who the hell I am to complain about
Gentoo and say what is right and what is wrong? You are right. But let me
illustrate one example:
Install a system and wait some weeks. Then go ahead and just reinstall all the
same packages with exactly the same version and revision as you did weeks ago
(after doing first a emerge --sync). And now tell me that you will never ever
see a configuration option changed after you reinstalled whole world. I can
tell you right now that you will see changes. And this is absolutely a "no go".
This should never ever happen. New configuration should automatically lead to a
new revision. But not in Gentoo land. They change things all the time without
bumping a revision. How the hell is one supposed to to quality assurance in
such an environment?
And this is just one example. I could go on and post you many, many more.
> >> I'm no good with C or dialog,
> >>
> > Dialog is ultra easy. If you know Shell programming then dialog should
> not be an issue for you.
> >
> > A simple dialog for choosing the storage backend:
> > ----
> > dialog --backtitle "DSPAM storage backend" --radiolist "Select DSPAM
> storage backend to use:" 10 40 4 $(dsbc=0;for dsb in $(dspam --version|sed -n
> "s:,: :g;s:.*\-\with\-storage\-driver=\([^']*\)'.*:\1:gp");do let
> dsbc+=1;echo -ne ${dsbc} ${dsb} $([ ${dsbc} -eq 1 ] && echo "on" || echo
> "off")"
> ";done)
> > ------
> >
> Looks easy enough, I'll give it a go :)
>
> >>>> 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.
> >>
> > Okay. I am going to post the next BETA/RC release in b.g.o and push it
> to CVS.
> >
> Great :)
>
:)
> --
> Regards,
> Tom
>
Steve
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
------------------------------------------------------------------------------
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
