Well let's see: the ebuild is the same since 2003; it uses the old portmap rather than the new rpcbind; it installs a static library but no header files… net-mail do you care about this or should we remove it?
Unless there are any objections I will pmask this one and fix net-mail/qpopper package to not depend on drac at all I will wait 48 hours before I proceed
Hey, don’t remove this, *unless* you can offer an alternative! What do you expect users like me to do, who used this for years, to make their mail system work? As you might expect, it’s also years, since I looked into these things. And I’m not interested in doing so, since everything works fine. This should be a general reminder hanging on everyone’s wall: If you mask something, *always* mention how the user can keep his system working the way it used to, without it. I.e. offer an alternative. Including a migration mini-HOWTO. Thank you.
You can keep the ebuild in a local overlay and keep doing your job like you used to
(In reply to comment #3) > You can keep the ebuild in a local overlay and keep doing your job like you > used to But that would mean, that masking it is pointless, since it works without problems. ;) Apparently, it has its problems, or you wouldn’t have masked it, would you? If those problems are of that type, that when I upgrade the next time, it will stop working because of incompatibilities, that using a local not masked ebuild is not going to help very much, is it? ;) So… what’s the wiser alternative? You know… in the long run…
(In reply to comment #4) > (In reply to comment #3) > > You can keep the ebuild in a local overlay and keep doing your job like you > > used to > > But that would mean, that masking it is pointless, since it works without > problems. ;) > Apparently, it has its problems, or you wouldn’t have masked it, would you? > If those problems are of that type, that when I upgrade the next time, it will > stop working because of incompatibilities, that using a local not masked ebuild > is not going to help very much, is it? ;) > > So… what’s the wiser alternative? You know… in the long run… > The problems are listed in first comment by Diego. They are more like QA problems. If you unmask it and keep it in a local overlay it will work for you as it used to
Aaahh, so in essence: It’s nasty to support, and so you stopped supporting it. But or course, anyone who want to use it, can do what he likes, since it works fine. He just should not come cry to you. Correct? :) Well, that I can understand. :) Although I wonder why nobody went, and contacted the developer (Gary Mills<mills@cc.umanitoba.ca> at the University of Manitoba.), so he could perhaps update the thing…
(In reply to comment #6) > Aaahh, so in essence: It’s nasty to support, and so you stopped supporting > it. But or course, anyone who want to use it, can do what he likes, since it > works fine. He just should not come cry to you. > Correct? :) It is not nasty otherwise we wouldn't have an ebuild in the first place. But there are issues in the package it self that are upstream failures not ours. Since upstream didn't bother to release a new version since 2003 why should we keep maintaining a dead package with multiple issues? > > Well, that I can understand. :) > > Although I wonder why nobody went, and contacted the developer (Gary > Mills<mills@cc.umanitoba.ca> at the University of Manitoba.), so he could > perhaps update the thing… > Do you really that he will work on these issues after 7 years? If you really care about this package you can ask him ( just point him to this bug ) This is the point of masking after all. Alter everyone that there are some serious issues with a package that should be fixed in the given timeframe (30-60 days) or it will be removed. So those who cared about it, step up and fix the issues
(In reply to comment #7) > It is not nasty otherwise we wouldn't have an ebuild in the first place. But > there are issues in the package it self that are upstream failures not ours. > Since upstream didn't bother to release a new version since 2003 why should we > keep maintaining a dead package with multiple issues? Eeeasy…. :) That’s exactly what I said. So we agree. But apparently you overlooked it in the rage. ;) No problem, I’ll repeat it: > > Well, that I can understand. :) > Do you really that he will work on these issues after 7 years? If you really > care about this package you can ask him ( just point him to this bug ) Hmm… I accidentally the whole question… ;) Well, of course I assume that the maintainer of an ebuild keeps in touch with the developer of the software. Otherwise it would be pretty weird. So I assume that the developer was already notified a looong time ago, but chose not to update the package. And this here is the obvious result. > This is the point of masking after all. Alter everyone that there are some > serious issues with a package that should be fixed in the given timeframe > (30-60 days) or it will be removed. So those who cared about it, step up and > fix the issues Now guess what I’m doing right now…? ;) I already contacted the developer, and sent him a link to this bug. Although I still think it’s the package maintainer’s job to be the translator between us. Whatever. The weather is great. So you can’t drag me down today. Enjoy it too. :) P.S.: Seems like your definition of “nasty” is weird. Because something can not have “serious issues” and be “not nasty” at the same time, IMHO. :)
(In reply to comment #8) > I already contacted the developer, and sent him a link to this bug. Although I > still think it’s the package maintainer’s job to be the translator between > us. Fine in theory, but there is no maintainer. %% epkginfo drac|grep Maintainer Maintainer: none One could argue that is is the net-mail team's job to do it, but they are understaffed too! Annoying cycle, eh? The only way to solve it is to a) remove packages that no one cares about, b) recruit more people.
(In reply to comment #9) > Fine in theory, but there is no maintainer. Ah, interesting. I thought Markos were the maintainer, since he created the bug. Thanks for the info. > The only way to solve it is to a) remove > packages that no one cares about, b) recruit more people. I agree 100%. Man, I wish I could throw some money that way. But hopefully I’ll soon be able to hire my own people. Then at least one is going to do Gentoo stuff. :)
I'll take this package as one of my servers still uses it. No removal. If there are issues with this package, please, open new bugs (one issue per bug). Thank you!
Markos it'll be great if you revert packages you've touched, or, please, give me a list. I'm using it with qpopper, but probably there were other packages I'm not aware about...
Markos, I found and reverted qpopper and net-mail/tpop3d. I hope it's all that was in the tree. BTW, why you did revbump on tpop3d?
Wait… what?? So saying you’ll be the maintainer, prevents it? Or are you going to resolve the problems with it too, Peter? :)
(In reply to comment #13) > Markos, I found and reverted qpopper and net-mail/tpop3d. I hope it's all that > was in the tree. BTW, why you did revbump on tpop3d? > Peter, I touched net-mail/qpopper-4.0.14 net-mail/qpopper-4.0.16 net-mail/tpop3d-1.5.4-r1 but I see you've already fix them :)
Thanks, Markos. (In reply to comment #14) > Wait… what?? So saying you’ll be the maintainer, prevents it? Or are you > going to resolve the problems with it too, Peter? :) Navid, if there are any bugs, please, report them separately and I'll do my best to fix them. I need this package so it'll stay in the tree.
(In reply to comment #16) > Navid, if there are any bugs, please, report them separately and I'll do my > best to fix them. I need this package so it'll stay in the tree. Me too. :) I thought that those “serious issues” (after all the reason why it went to masked in the first place) were a bug. How about creating one for those issues then? :)
Peter, would be a nice idea for you to solve the problems posed by this bug before stopping a removal and unmasking a package leaving the same exact problems there.
Diego, 1. there is no header required for this library. Packages just know how to use it. Take a look at qpopper - it links with library and never includes drac.h. 2. portmap v.s. rpcbind - is this an issue? Now if there are any issue left, please, open new bug report. This bug is still invalid and full of non-relevant information.
(In reply to comment #19) > Diego, > > 1. there is no header required for this library. Packages just know how to use > it. Take a look at qpopper - it links with library and never includes drac.h. Then why does it install libdrac.a ?
(In reply to comment #20) > Then why does it install libdrac.a ? > > 1. there is no header required for this library. Packages just know how to use > > it. Take a look at qpopper - it links with library and never includes drac.h. From qpopper's configure.ac: AC_ARG_WITH(drac, [ --with-drac=lib-path Compile in DRAC support], dracauth="$withval" ) if test "$dracauth" != "no"; then AC_MSG_RESULT(Compiling in DRAC support) AC_DEFINE(DRAC_AUTH) if test "$dracauth" != "yes"; then LIBS="$LIBS -L$dracauth -ldrac" else LIBS="$LIBS -ldrac" fi fi from drac.c: int drac_it ( POP *p ) { char *err = NULL; int rslt = 0; if ( p->drac_host != NULL && *p->drac_host != '\0' ) { rslt = dracauth ( p->drac_host, inet_addr(p->ipaddr), &err ); if ( rslt != 0 ) pop_log ( p, POP_PRIORITY, HERE, "[drac]: dracauth returned %d: %s", rslt, err ); else { pop_log ( p, POP_PRIORITY, HERE, "[drac]: login by %s from host %s (%s)", p->user, p->client, p->ipaddr ); return POP_SUCCESS; } } else { pop_log ( p, POP_PRIORITY, HERE, "drac not used; p->drac_host null" ); } return POP_FAILURE; } dracauth() is the function from drac library.
I got an answer from Gary Mills. Quoting here: ———————————————————————————————————————————————————————————— > Hello, I’m writing you, because according to the package maintainer > for drac [ed: I didn’t know that you don’t were the maintainer, back then, Markos] at Gentoo, wants to throw out the package because “the ebuild > is the same since 2003; it uses the old portmap rather than the new > rpcbind; it installs a static library but no header files…” I only run drac on Solaris, but the code is intended to be portable to other operating systems. It certainly uses rpcbind on Solaris, but I believe it's only a new name for an enhanced facility. I don't know why Linux would have both. Yes, it builds a static library and has no corresponding header file. That's certainly inconvenient, but this is the first report I've seen that it's a problem. That's perhaps why I haven't changed it in years. Other people are welcome to fix those problems if they submit the changes to me. > As I installed drac on my hardened server, a loong time ago, and don’t > know an alternative, I wonder if you could fix/update it, or recommend > an alternative? The alternative is SMTP authentication. We use that here as well. It's used in the majority of cases anyway because ISPs now require their customers to use the client port and SMTP authentication. I plan to stop using drac here one of these years. ———————————————————————————————————————————————————————————— I think SMTP authentication certainly is a good replacement, and wonder why I didn’t think of that before. So for me: I’ll replace drac by that, and call it a WORKSFORME. :)
