Mailing List Archive

On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote:
> due to massive code duplication in netqmail, qmail-ldap, qmail-mysql,
> mini-qmail and other 3-rd party applications for qmail i have started
> to move functionality into a first qmail.eclass draft.

I already proposed moving the prime functionality into an eclass and it
was refused back then. qmail-mysql and qmail-ldap may get removed soon.

And as the netqmail ebuild maintainer, I want the ebuild to be as simple
as possible, that is, no external dependencies where possible.

> Attached is the eclass and a sample how to use it with netqmail.

It seems like you aren't interested in communication with the
maintainer, otherwise you would've CC'ed me.

Greets,
Michael

--
http://hansmi.ch/
--
gentoo-dev@gentoo.org mailing list

Michael Hanselmann napsal(a):
> On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote:
>> due to massive code duplication in netqmail, qmail-ldap, qmail-mysql,
>> mini-qmail and other 3-rd party applications for qmail i have started
>> to move functionality into a first qmail.eclass draft.

> And as the netqmail ebuild maintainer, I want the ebuild to be as simple
> as possible, that is, no external dependencies where possible.

I wouldn't exactly call the current netqmail ebuild 'simple', on a quick
look. Hmmm... :)

>> Attached is the eclass and a sample how to use it with netqmail.
>
> It seems like you aren't interested in communication with the
> maintainer, otherwise you would've CC'ed me.

Erm? This was completely uncalled for, I'd say?!


--
Best regards,

Jakub Moc
mailto:jakub@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E

... still no signature ;)

On Fri, 13 Jul 2007 14:34:26 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote:
> > due to massive code duplication in netqmail, qmail-ldap,
> > qmail-mysql, mini-qmail and other 3-rd party applications for qmail
> > i have started to move functionality into a first qmail.eclass
> > draft.
>
> I already proposed moving the prime functionality into an eclass and
> it was refused back then. qmail-mysql and qmail-ldap may get removed
> soon.

qmail-ldap will not be removed for sure, since i maintain it currently.

>
> And as the netqmail ebuild maintainer, I want the ebuild to be as
> simple as possible, that is, no external dependencies where possible.

so, you suggest it is a better way to duplicate tons of code in 4
ebuilds?

>
> > Attached is the eclass and a sample how to use it with netqmail.
>
> It seems like you aren't interested in communication with the
> maintainer, otherwise you would've CC'ed me.

appearantly, you are subscribed to gentoo-dev.

>
> Greets,
> Michael
>

On a sidenote, qmail has a huge amount of open bugs, and has generally
gotten no love in the past time, so i wonder if it actually was/is
maintained.
--
gentoo-dev@gentoo.org mailing list

Michael Hanselmann kirjoitti:
>
> It seems like you aren't interested in communication with the
> maintainer, otherwise you would've CC'ed me.
>

We are all required to subscribe to this mailing list... Should be easy
enough to spot the thread.

Regards,
Petteri
--
gentoo-dev@gentoo.org mailing list

On Fri, 2007-07-13 at 14:53 +0200, Jakub Moc wrote:
> Michael Hanselmann napsal(a):
> > On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote:
>
> > It seems like you aren't interested in communication with the
> > maintainer, otherwise you would've CC'ed me.
>
> Erm? This was completely uncalled for, I'd say?!

Looking at traffic going both ways I don't think it was meant harshly or
etc. More a surprise to the current maintainer. That they weren't
contacted to get their feedback on something they are directly
responsible for. Before going over their heads or around the bush to get
opinions from others.

I don't think it was intentionally done. But usually, not sure if it's
stated in policy, it's best to try to contact a maintainer first,
directly. If one exists, if not the someone maintaining the herd then.
Discussing and ideas, thoughts, issues, etc there. Then based on that,
elevate the conversation to say -dev ml or etc for all to be involved.

I am sure lots of us have lots of ideas about allot of packages. But
only a few of us take enough time to commit to being a packages
maintainer. Those willing to put their neck on the line should be the
first stop, IMHO.

Simple misunderstanding miss-communication. :)

--
William L. Thomson Jr.
Gentoo/Java

On Fri, 13 Jul 2007 11:22:47 -0400
"William L. Thomson Jr." <wltjr@gentoo.org> wrote:

> On Fri, 2007-07-13 at 14:53 +0200, Jakub Moc wrote:
> > Michael Hanselmann napsal(a):
> > > On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote:
> >
> > > It seems like you aren't interested in communication with the
> > > maintainer, otherwise you would've CC'ed me.
> >
> > Erm? This was completely uncalled for, I'd say?!
>
> Looking at traffic going both ways I don't think it was meant harshly
> or etc. More a surprise to the current maintainer. That they weren't
> contacted to get their feedback on something they are directly
> responsible for. Before going over their heads or around the bush to
> get opinions from others.

Actually i am qmail maintainer and also been in the qmail herd for
quite some time...

>
> I don't think it was intentionally done. But usually, not sure if it's
> stated in policy, it's best to try to contact a maintainer first,
> directly. If one exists, if not the someone maintaining the herd then.
> Discussing and ideas, thoughts, issues, etc there. Then based on that,
> elevate the conversation to say -dev ml or etc for all to be involved.
>
> I am sure lots of us have lots of ideas about allot of packages. But
> only a few of us take enough time to commit to being a packages
> maintainer. Those willing to put their neck on the line should be the
> first stop, IMHO.
>
> Simple misunderstanding miss-communication. :)
>
--
gentoo-dev@gentoo.org mailing list

On Fri, Jul 13, 2007 at 05:37:16PM +0300, Petteri Räty wrote:
> We are all required to subscribe to this mailing list... Should be easy
> enough to spot the thread.

You know, sometimes I get tired of all the flames and pointless
discussions and mark all mails as read. If something should be read by a
certain person, it's usually better to send it to the list *and* CC the
person in question.

Greets,
Michael

--
http://hansmi.ch/

On Fri, Jul 13, 2007 at 07:05:51PM +0200, Benedikt Boehm wrote:
> Actually i am qmail maintainer and also been in the qmail herd for
> quite some time...

No, actually you're in the qmail herd and maintainer of the
net-mail/qmail-ldap package. This doesn't make you a netqmail (the
package I care about) maintainer.

Greets,
Michael

--
http://hansmi.ch/

On Fri, Jul 13, 2007 at 03:04:27PM +0200, Benedikt Boehm wrote:
> qmail-ldap will not be removed for sure, since i maintain it currently.

Okay, my status there was outdated. We were at least discussing it at
some point in history.

> > And as the netqmail ebuild maintainer, I want the ebuild to be as
> > simple as possible, that is, no external dependencies where possible.

> so, you suggest it is a better way to duplicate tons of code in 4
> ebuilds?

I'll think about it.

> appearantly, you are subscribed to gentoo-dev.

… which doesn't necessarily mean I read it.

> On a sidenote, qmail has a huge amount of open bugs, and has generally
> gotten no love in the past time, so i wonder if it actually was/is
> maintained.

qmail != netqmail. To my knowledge, we have only one outstanding bug
there, the one with man pages colliding, nothing critical. Since I also
have other things in life with higher priorities than Gentoo, it has to
wait. However, I should get to it during the week or at latest two
weeks.

Greets,
Michael

--
http://hansmi.ch/

On Fri, Jul 13, 2007 at 11:22:47AM -0400, William L. Thomson Jr. wrote:
> > > It seems like you aren't interested in communication with the
> > > maintainer, otherwise you would've CC'ed me.

> > Erm? This was completely uncalled for, I'd say?!

To Jakub: It was. Sending such things to a public list is fine, as long
as the affected persons get informed, too. Otherwise it can be seen like
a complaint behind someone's back. I'm sure you've experience with that,
do you?

> Looking at traffic going both ways I don't think it was meant harshly or
> etc. More a surprise to the current maintainer.

Indeed it was surprising. “Who is he to come around with such a thing on
a public list, without CC'ing me?”

> But usually, not sure if it's stated in policy, it's best to try to
> contact a maintainer first, directly.

Such a thing wouldn't even have to be in policy. It's just common sense.

Anyway, let's end it here and get back to technical stuff.

Greets,
Michael

--
http://hansmi.ch/

On Sat, 14 Jul 2007 23:02:00 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> On Fri, Jul 13, 2007 at 03:04:27PM +0200, Benedikt Boehm wrote:
> > qmail-ldap will not be removed for sure, since i maintain it
> > currently.
>
> Okay, my status there was outdated. We were at least discussing it at
> some point in history.
>
> > > And as the netqmail ebuild maintainer, I want the ebuild to be as
> > > simple as possible, that is, no external dependencies where
> > > possible.
>
> > so, you suggest it is a better way to duplicate tons of code in 4
> > ebuilds?
>
> I'll think about it.
>
> [...]
>
> > On a sidenote, qmail has a huge amount of open bugs, and has
> > generally gotten no love in the past time, so i wonder if it
> > actually was/is maintained.
>
> qmail != netqmail. To my knowledge, we have only one outstanding bug
> there, the one with man pages colliding, nothing critical. Since I
> also have other things in life with higher priorities than Gentoo, it
> has to wait. However, I should get to it during the week or at latest
> two weeks.

As it seems, you do not have the time and/or interest to cleanup the
qmail mess, but don't want anyone to touch (net)qmail ebuilds either, i
have put the updated ebuilds for qmail and friends into my overlay. [1]

Maybe we can get them into the tree some time in the future.

Bene

[1]
http://planet.gentoo.org/developers/hollow/2007/07/15/experimental_qmail_ebuilds
--
gentoo-dev@gentoo.org mailing list

On Sun, Jul 15, 2007 at 03:07:28AM +0200, Benedikt Boehm wrote:
> As it seems, you do not have the time and/or interest to cleanup the
> qmail mess, but don't want anyone to touch (net)qmail ebuilds either, i
> have put the updated ebuilds for qmail and friends into my overlay. [1]

You interpret something into it which isn't true. I'm not “holding” it.
Publishing such unverified interpretations publically isn't exactly
nice, too. It's just that I don't have time today or tomorrow to look
more exactly into it, or, more exactly, I have things with higher
priorities to be done first (but also Free Software related!). And as
the current maintainer I just said “no” to your code (for now). There's
nothing wrong with doing that if I'm not accepting it (due to whatever
reason). You didn't ask to take over maintainership.

Doing a change like this to an ebuild has to be well thought, reviewed
and can't be done withing hours. netqmail is rather fragile to breakage
and we don't want our users to loose e-mails due to our failures, do we?

Now, you should correct that blog entry (I'm not going into why moving
topics from MLs to blogs is very bad) to actually state true facts and
then wait a few days. I'll have some time during this week.

Greets,
Michael

--
http://hansmi.ch/

On Sun, 15 Jul 2007 13:19:08 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> On Sun, Jul 15, 2007 at 03:07:28AM +0200, Benedikt Boehm wrote:
> > As it seems, you do not have the time and/or interest to cleanup the
> > qmail mess, but don't want anyone to touch (net)qmail ebuilds
> > either, i have put the updated ebuilds for qmail and friends into
> > my overlay. [1]
>
> You interpret something into it which isn't true. I'm not “holding”
> it. Publishing such unverified interpretations publically isn't
> exactly nice, too. It's just that I don't have time today or tomorrow
> to look more exactly into it, or, more exactly, I have things with
> higher priorities to be done first (but also Free Software related!).
> And as the current maintainer I just said “no” to your code (for
> now). There's nothing wrong with doing that if I'm not accepting it
> (due to whatever reason). You didn't ask to take over maintainership.

In fact you haven't been that nice either, but honestly i don't care.
Therefore i have just moved the ebuilds to my overlay until you can
review them ...

> Doing a change like this to an ebuild has to be well thought, reviewed
> and can't be done withing hours. netqmail is rather fragile to
> breakage and we don't want our users to loose e-mails due to our
> failures, do we?

... so that it can be tested by those who feel like.

> Now, you should correct that blog entry (I'm not going into why moving
> topics from MLs to blogs is very bad) to actually state true facts and
> then wait a few days. I'll have some time during this week.
>
> Greets,
> Michael
>
--
gentoo-dev@gentoo.org mailing list

Hello Benedikt

On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote:
> It is basically netqmail split into much smaller chunks so they can be
> reused by other qmail variants as well.

Okay, I looked through it and found some things which need
reconsideration. I agree that user creation and such things can be
easily done in an eclass. However, functions like qmail_src_unpack
should be done in the ebuild. Putting them in an eclass and just doing
"if (a) { … } else if (b) { … }" makes it harder to understand and
unneccessarily complicated. qmail_base_install should be split in
smaller functions, maybe with callbacks (if possible in bash). In the
end the ebuild shouldn't contain any package-specific code. Can you look
into it again?

Greets,
Michael

--
http://hansmi.ch/

On Fri, 20 Jul 2007 11:52:02 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> Hello Benedikt
>
> On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote:
> > It is basically netqmail split into much smaller chunks so they can
> > be reused by other qmail variants as well.
>
> Okay, I looked through it and found some things which need
> reconsideration. I agree that user creation and such things can be
> easily done in an eclass. However, functions like qmail_src_unpack
> should be done in the ebuild. Putting them in an eclass and just doing
> "if (a) { … } else if (b) { … }" makes it harder to understand and
> unneccessarily complicated.

I absolutely agree here, it is just too ugly.

> qmail_base_install should be split in
> smaller functions, maybe with callbacks (if possible in bash).

There is now qmail_mini_install (called by every qmail ebuild) and
qmail_{full,man,sendmail}_install for the rest of a full blown install.

I'm not sure what you mean with "callbacks" here, maybe you can
elaborate?

> In the
> end the ebuild shouldn't contain any package-specific code. Can you
> look into it again?

The qmail_*_install changes are already in my overlay, i will look into
removing the unpack stuff from the eclass together with some
DEPEND/IUSE cleanups to get rid of qmail_mini() tomorrow.

HTH,
Bene
--
gentoo-dev@gentoo.org mailing list

On Fri, Jul 20, 2007 at 10:05:23PM +0200, Benedikt Boehm wrote:
> > qmail_base_install should be split in smaller functions, maybe with
> > callbacks (if possible in bash).

> There is now qmail_mini_install (called by every qmail ebuild) and
> qmail_{full,man,sendmail}_install for the rest of a full blown install.

> I'm not sure what you mean with "callbacks" here, maybe you can
> elaborate?

If we have a common part which cannot, due to whatever reason, be split
into several functions, but we've to do something package specific in
between, we need callbacks. Just a sample (might not work at all, I'm
not that much into eclasses):

foo.eclass:
foo_src_install() {
# Some prefix code
# …

package_specific_code

# Some postfix code
# …
}

foo-simple.ebuild:
src_install() { foo_src_install }
package_specific_code() {
# code for foo-simple
}

foo-adv.ebuild:
src_install() { foo_src_install }
package_specific_code() {
# code for foo-adv
}

> The qmail_*_install changes are already in my overlay,

How can I get it using SVN? Looking at the site for more than a minute
shouldn't be required to find it.

Btw.: you didn't correct your blog posting to show the actual facts.

Thanks,
Michael

--
http://hansmi.ch/

On Fri, 20 Jul 2007 23:17:46 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> On Fri, Jul 20, 2007 at 10:05:23PM +0200, Benedikt Boehm wrote:
> > > qmail_base_install should be split in smaller functions, maybe
> > > with callbacks (if possible in bash).
>
> > There is now qmail_mini_install (called by every qmail ebuild) and
> > qmail_{full,man,sendmail}_install for the rest of a full blown
> > install.
>
> > I'm not sure what you mean with "callbacks" here, maybe you can
> > elaborate?
>
> If we have a common part which cannot, due to whatever reason, be
> split into several functions, but we've to do something package
> specific in between, we need callbacks. Just a sample (might not work
> at all, I'm not that much into eclasses):
>
> foo.eclass:
> foo_src_install() {
> # Some prefix code
> # …
>
> package_specific_code
>
> # Some postfix code
> # …
> }
>
> foo-simple.ebuild:
> src_install() { foo_src_install }
> package_specific_code() {
> # code for foo-simple
> }
>
> foo-adv.ebuild:
> src_install() { foo_src_install }
> package_specific_code() {
> # code for foo-adv
> }

i guess this could be done with some "eval" foo... going to run some
tests the next days

>
> > The qmail_*_install changes are already in my overlay,
>
> How can I get it using SVN? Looking at the site for more than a minute
> shouldn't be required to find it.

svn co http://overlays.gentoo.org/svn/dev/hollow

>
> Btw.: you didn't correct your blog posting to show the actual facts.
>
> Thanks,
> Michael
>
--
gentoo-dev@gentoo.org mailing list

On Fri, 20 Jul 2007 11:52:02 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> Hello Benedikt
>
> On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote:
> > It is basically netqmail split into much smaller chunks so they can
> > be reused by other qmail variants as well.
>
> Okay, I looked through it and found some things which need
> reconsideration. I agree that user creation and such things can be
> easily done in an eclass. However, functions like qmail_src_unpack
> should be done in the ebuild. Putting them in an eclass and just doing
> "if (a) { … } else if (b) { … }" makes it harder to understand and
> unneccessarily complicated.

i thought about this, but i'd really like to see things like qmail-spp
and the gentoo qmail tarball be handled by the eclass, on the other
hand i agree that unpacking netqmail or qmail based on $FOO is not the
best idea. any suggestions?

>
> Greets,
> Michael
>

Bene
--
gentoo-dev@gentoo.org mailing list

On Mon, 23 Jul 2007 21:55:16 +0200
Benedikt Boehm <hollow@gentoo.org> wrote:

> On Fri, 20 Jul 2007 23:17:46 +0200
> Michael Hanselmann <hansmi@gentoo.org> wrote:
>
> > On Fri, Jul 20, 2007 at 10:05:23PM +0200, Benedikt Boehm wrote:
> > > > qmail_base_install should be split in smaller functions, maybe
> > > > with callbacks (if possible in bash).
> >
[...]
> >
> > > I'm not sure what you mean with "callbacks" here, maybe you can
> > > elaborate?
> >
> > If we have a common part which cannot, due to whatever reason, be
> > split into several functions, but we've to do something package
> > specific in between, we need callbacks. Just a sample (might not
> > work at all, I'm not that much into eclasses):
> >
[...]
>
> i guess this could be done with some "eval" foo... going to run some
> tests the next days
>

I figured that we can simply use declare to check if a function exists,
so i implemented hooks for all install functions and provided a
combined qmail_src_install that calls all install functions.

I also moved the unpack stuff back into the ebuilds, only genqmail
and qmail-spp remain with a little unpack function in the eclass...

Bene
--
gentoo-dev@gentoo.org mailing list

Hello Benedikt

Sorry for my long response times.

On Mon, Jul 23, 2007 at 09:58:17PM +0200, Benedikt Boehm wrote:
> i thought about this, but i'd really like to see things like qmail-spp
> and the gentoo qmail tarball be handled by the eclass, on the other
> hand i agree that unpacking netqmail or qmail based on $FOO is not the
> best idea. any suggestions?

I really don't see the point of having qmail_spp_src_unpack and all of
these qmail-spp related variables. There have to be different diffs
anyway for other sources, making it more complicated with that many
variables. Aren't you overengineering here?

Now some things I noticed while going through, in no special order:
- Why need_qmail? It slows down cache regeneration and is really unneeded.
- In qmail_man_install you rename some manpages. Can you please add a
comment on why you do this?
- You're very inconsistent with variable quoting. Please quote them
everywhere except the places where you're absolutly sure there will be
no spaces (or other special characters) in them. Maybe the original
netqmail has some of these issues, too, but now we can fix them.
- Don't align stuff like on the last two lines in qmail_src_install.
- The "use gencertdaily" thing in qmail_ssl_generate works, but doesn't
look so nice. How about this?
use gencertdaily && \
CRON_FOLDER=cron.daily || \
CRON_FOLDER=cron.hourly
- Limit line length to 80 characters (with tabs at 8 spaces).
- I don't like the custom tarball. How do you want to build and
redistribute it without depending on a single person? Its sources need
to reside completly on Gentoo infrastructure.
- If I remember correctly, elog shouldn't be used for empty lines like
in qmail_supervise_config_notice. Use echo instead for them.

So, now you should have something to chew on again. :-)

Thanks,
Michael

--
http://hansmi.ch/

On Fri, 27 Jul 2007 13:08:36 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> - If I remember correctly, elog shouldn't be used for empty lines like
> in qmail_supervise_config_notice. Use echo instead for them.

You remember incorrectly (though I don't think I ever said anything
about it). You should use elog/ewarn/... without arguments to separate
different message items (with echo it might look better on the console
during the build, but worse in the final log).

Marius
--
gentoo-dev@gentoo.org mailing list

On Fri, 27 Jul 2007 13:08:36 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> Hello Benedikt
>
> Sorry for my long response times.
>
> On Mon, Jul 23, 2007 at 09:58:17PM +0200, Benedikt Boehm wrote:
> > i thought about this, but i'd really like to see things like
> > qmail-spp and the gentoo qmail tarball be handled by the eclass, on
> > the other hand i agree that unpacking netqmail or qmail based on
> > $FOO is not the best idea. any suggestions?
>
> I really don't see the point of having qmail_spp_src_unpack and all of
> these qmail-spp related variables. There have to be different diffs
> anyway for other sources, making it more complicated with that many
> variables. Aren't you overengineering here?

Well, i think the unpack stuff could be handled in the ebuild, but i'd
still like to keep dospp, so ebuilds like vpopmail can install
spp-plugins in a standardized way..

> Now some things I noticed while going through, in no special order:
> - Why need_qmail? It slows down cache regeneration and is really
> unneeded.

yeah. will fix this soon.

> - In qmail_man_install you rename some manpages. Can you please add a
> comment on why you do this?

done.

> - You're very inconsistent with variable quoting. Please quote them
> everywhere except the places where you're absolutly sure there will
> be no spaces (or other special characters) in them. Maybe the original
> netqmail has some of these issues, too, but now we can fix them.

done (at least in the eclass)

> - Don't align stuff like on the last two lines in qmail_src_install.

done

> - The "use gencertdaily" thing in qmail_ssl_generate works, but
> doesn't look so nice. How about this?
> use gencertdaily && \
> CRON_FOLDER=cron.daily || \
> CRON_FOLDER=cron.hourly

done

> - Limit line length to 80 characters (with tabs at 8 spaces).

will look at this later

> - I don't like the custom tarball. How do you want to build and
> redistribute it without depending on a single person? Its sources
> need to reside completly on Gentoo infrastructure.

yes, i'd suggest to put it in svn, just like we do with the apache
tarball, and create a script for tar/upload etc.. probably most could
be copied from the apache script..

Bene
--
gentoo-dev@gentoo.org mailing list

On Mon, Jul 30, 2007 at 01:20:43PM +0200, Benedikt Boehm wrote:
> Well, i think the unpack stuff could be handled in the ebuild, but i'd
> still like to keep dospp, so ebuilds like vpopmail can install
> spp-plugins in a standardized way..

dospp is fine. Well, maybe rename it to doqmail-spp to make the name
more clear.

> > - I don't like the custom tarball. How do you want to build and
> > redistribute it without depending on a single person? Its sources
> > need to reside completly on Gentoo infrastructure.

> yes, i'd suggest to put it in svn, just like we do with the apache
> tarball, and create a script for tar/upload etc.. probably most could
> be copied from the apache script..

Which SVN? svn.g.o?

Greets,
Michael

--
http://hansmi.ch/

On Mon, 30 Jul 2007 14:23:52 +0200
Michael Hanselmann <hansmi@gentoo.org> wrote:

> On Mon, Jul 30, 2007 at 01:20:43PM +0200, Benedikt Boehm wrote:
> > > - I don't like the custom tarball. How do you want to build and
> > > redistribute it without depending on a single person? Its
> > > sources need to reside completly on Gentoo infrastructure.
>
> > yes, i'd suggest to put it in svn, just like we do with the apache
> > tarball, and create a script for tar/upload etc.. probably most
> > could be copied from the apache script..
>
> Which SVN? svn.g.o?

Yep. Maybe it is also a good idea to make a stand-alone ebuild for the
qmail-spp plugins in the tarball i have collected, cleaned up and
tested so far, so we do not need to handle that in the qmail ebuilds..?

>
> Greets,
> Michael
>

Bene
--
gentoo-dev@gentoo.org mailing list