Re: [gentoo-dev] [RFC] qmail.eclass draft
On Fri, 27 Jul 2007 13:08:36 +0200 Michael Hanselmann [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/ pgpntoOCV84Y2.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Mon, 30 Jul 2007 14:23:52 +0200 Michael Hanselmann [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Mon, Jul 30, 2007 at 04:51:17PM +0200, Benedikt Boehm wrote: 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..? That's a great idea. However, can control/smtpplugins take absolute paths? Otherwise we'd still have to symlink them into /var/qmail*/plugins. Greets, Michael -- http://hansmi.ch/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/ pgpVhPBmnhF0g.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Fri, 27 Jul 2007 13:08:36 +0200 Michael Hanselmann [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Mon, 23 Jul 2007 21:55:16 +0200 Benedikt Boehm [EMAIL PROTECTED] wrote: On Fri, 20 Jul 2007 23:17:46 +0200 Michael Hanselmann [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Fri, 20 Jul 2007 23:17:46 +0200
Michael Hanselmann [EMAIL PROTECTED] 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
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Fri, 20 Jul 2007 11:52:02 +0200
Michael Hanselmann [EMAIL PROTECTED] 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
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/
pgpN5aX0DMOPJ.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Fri, 20 Jul 2007 11:52:02 +0200
Michael Hanselmann [EMAIL PROTECTED] 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
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/
pgpheRVzzvEaH.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/ pgpumgWqiSWFH.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Sun, 15 Jul 2007 13:19:08 +0200 Michael Hanselmann [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/ pgpYzKszrBXim.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/ pgpiM8eZ396UK.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/ pgpI6401kiaE1.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/ pgpZmaI9WrlEr.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Sat, 14 Jul 2007 23:02:00 +0200 Michael Hanselmann [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
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/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
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:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] qmail.eclass draft
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 -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [RFC] qmail.eclass draft
Hi all, 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. It is basically netqmail split into much smaller chunks so they can be reused by other qmail variants as well. Additionally configuration files supplied by gentoo have been moved from $FILESDIR to a seperate tarball. [1] Attached is the eclass and a sample how to use it with netqmail. Comments and suggestions are more than welcome! Bene [1] http://dev.gentoo.org/~hollow/genqmail-20070713.tar.bz2 prime.eclass Description: Binary data qmail.eclass Description: Binary data netqmail-1.05-r9.ebuild Description: Binary data
Re: [gentoo-dev] [RFC] qmail.eclass draft
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Fri, 13 Jul 2007 14:34:26 +0200 Michael Hanselmann [EMAIL PROTECTED] 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. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Fri, 13 Jul 2007 11:22:47 -0400 William L. Thomson Jr. [EMAIL PROTECTED] 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. :) -- [EMAIL PROTECTED] mailing list
