Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 154782 - dev-perl/Authen-SASL-Cyrus-server-0.13: new ebuild for Authen::SASL::Cyrus
Summary: dev-perl/Authen-SASL-Cyrus-server-0.13: new ebuild for Authen::SASL::Cyrus
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Default Assignee for New Packages
URL: http://search.cpan.org/~pboettch/Auth...
Whiteboard:
Keywords: EBUILD
Depends on:
Blocks:
 
Reported: 2006-11-11 03:16 UTC by Martin von Gagern
Modified: 2014-12-14 21:54 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Authen-SASL-Cyrus-0.12.ebuild (Version 1) (Authen-SASL-Cyrus-0.12.ebuild,628 bytes, text/plain)
2006-11-11 03:19 UTC, Martin von Gagern
Details
Authen-SASL-Cyrus-server-0.13.ebuild (Version 1) (Authen-SASL-Cyrus-server-0.13.ebuild,809 bytes, text/plain)
2006-12-11 04:01 UTC, Martin von Gagern
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2006-11-11 03:16:36 UTC
I just created an ebuild for Authen::SASL::Cyrus based on Authen-SASL-2.10.ebuild.
I did not look at any internals of perl-module.elass, as my simple copy & paste ebuild seems to work well enough.

Authen::SASL::Cyrus is useful for GSSAPI (Kerberos) authentication to e.g. LDAP.

The license of this module is not known to cpan. Perhaps it would make sense for a gentoo dev to contact the author, to avoid me having to relay any messages.
Comment 1 Martin von Gagern 2006-11-11 03:19:34 UTC
Created attachment 101666 [details]
Authen-SASL-Cyrus-0.12.ebuild (Version 1)

Based on Authen-SASL-2.10.ebuild.
Comment 2 Martin von Gagern 2006-12-10 14:28:35 UTC
I encountered a problem with Net::SMTP when this module is installed.

Take this source:
######################################################################
require Net::SMTP;
# use Authen::SASL qw(Perl); # needed to avoid conflict with Cyrus

$smtp = Net::SMTP->new("mail.gmx.net") or die $smtp->message;
$smtp->auth("foo", "bar")
    or print STDERR "Authentication failed: ", $smtp->message, "\n";
$smtp->quit
    or die $smtp->message;
######################################################################

In this form you get the following error:
  Unknown callback: 'authname'. (user|auth|language|pass)

With the use line enabled things work as they should.
I guess this is an upstream problem, but I report it here as well. I also wrote an email to Mark Adamson, concerning this issue as well as the question of licensing.

While looking again at CPAN I noticed there are modules Authen-SASL-Cyrus-0.12-server and *-0.13-server, by Patrick Boettcher. To me the branch without the added -server looks more official right now, but when you consider adding this module, you might want to know about this, as those releases are more recent than the version by Mr. Adamson.
Comment 3 Martin von Gagern 2006-12-11 04:01:53 UTC
Created attachment 103789 [details]
Authen-SASL-Cyrus-server-0.13.ebuild (Version 1)

My eMail to Mr. Adamson returned because of exceeded quota, so I guess it might become difficult to contact him about license or bugs.
So I got the Authen-SASL-Cyrus-0.13-server module working. For the ebuild name I moved the -server in front of the version. The module now builds and installs all right, has been tested in contacting an LDAP server as well as with this program from comment 2, so I'd suggest preferring this version.
Comment 4 Martin von Gagern 2006-12-11 04:19:25 UTC
Changed URL from http://search.cpan.org/~adamson/Authen-SASL-Cyrus-0.12/ to
http://search.cpan.org/~pboettch/Authen-SASL-Cyrus-0.13-server/ and Summary from dev-perl/Authen-SASL-Cyrus-0.12 to dev-perl/Authen-SASL-Cyrus-server-0.13 to reflect the new ebuild I suggest for inclusion.
Comment 5 Michael Cummings (RETIRED) gentoo-dev 2007-01-09 12:50:37 UTC
Does g-cpan fail to produce a working ebuild for this? Or does this fill a dep somewhere?
Comment 6 Martin von Gagern 2007-01-09 13:45:35 UTC
(In reply to comment #5)
> Does g-cpan fail to produce a working ebuild for this?

g-cpan will fetch Authen-SASL-Cyrus-0.12 but not -0.13-server,
which I would prefer due to the problem described in comment #2.
At least I found no way to get g-cpan choose the "server" version.

> Or does this fill a dep somewhere?

Not a dep stated in any ebuild I know of. But perldoc Authen::SASL states Authen::SASL::Cyrus as the preferred implementation, so users might expect this to be provided as a premade ebuild instead of getting used to g-cpan.
Comment 7 Martin von Gagern 2007-07-04 01:26:44 UTC
Today updating from a CPAN-installed 0.12 to the here suggested 0.13-server version of Authen::SASL::Cyrus solved another problem for me on a different system, where an LDAP request failed to return even though apparently all data had been sent.

Considering that this 0.13-server version has been out now for two years and is already deemed stable by Debian (with one patch, though), I would really appreciate having this in portage soon. For the Debian package see
http://packages.debian.org/stable/perl/libauthen-sasl-cyrus-perl
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2008-02-27 18:06:52 UTC
Is this thing actually needed for anything?

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap2
Comment 9 Martin von Gagern 2008-02-27 20:26:49 UTC
(In reply to comment #8)
> Is this thing actually needed for anything?

This is needed in order to allow Perl scripts to use the stability and performance of the cyrus sasl library.

Authen::SASL defaults to Cyrus and only falls back to the Perl implementation, as stated in comment #6. I guess that's for a good reason. The Perl-only implementation is no substitute, as the example from comment #2 demonstrates.

The Perl implementation does not provide GSSAPI with security layers. The documentation of Authen::SASL::Perl::GSSAPI tells the programmer to use Authen::SASL::Cyrus instead.

> [Link to Ebuild policy / Specific guidelines / Perl]

Quoting from the Handbook

> New Perl modules are to be added to portage only when one of the following
> conditions is met:

This ebuild meets two conditions, so I'd think it should qualify.

> * The module(s) fulfill a dependency

None that I'm aware of. Only the Authen-SASL documentation references it.

> * The module(s) cannot be handled by g-cpan

True, as stated in comment #6.

> * The module(s) add functionality to existing ebuilds

True. Adds functionality to dev-perl/Authen-SASL as described above.
      Adds Perl language bindings to dev-libs/cyrus-sasl.

> * The module(s) provide tools, applications or other features
    (i.e. more than what their .PM offers)

No, except for .so wrapper library, .pod files and stuff like that.

Debian e.g. provides Authen::SASL::Cyrus from the same CPAN package as well, so programmers working on Debian are probably likely to write scripts that use it.
http://packages.debian.org/etch/libauthen-sasl-cyrus-perl
Comment 10 Martin von Gagern 2008-09-04 09:19:57 UTC
Comment on attachment 101666 [details]
Authen-SASL-Cyrus-0.12.ebuild (Version 1)

Obsoleting the 0.12 ebuild, as the 0.13-server version should be preferred.
Comment 11 Martin von Gagern 2009-01-02 11:47:50 UTC
This is now in the sunrise overlay. You can find it at:
http://overlays.gentoo.org/svn/proj/sunrise/reviewed/dev-perl/Authen-SASL-Cyrus-server

I've been a bit quick to push this into sunrise, while the bug here is still assigned to perl, not maintainer-wanted. Still, it got reviewed, and is available for testing there. Of course I'd love to see this officially in portage as soon as possible, if the perl team would do that. If not, reassigning this bug and cc'ing perl would maybe be appropriate, I don't know.

By the way, I've clarified the license as well. http://search.cpan.org/~pboettch/Authen-SASL-Cyrus-0.13-server/Cyrus.pod#COPYRIGHT states: "This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself." So it's now LICENSE="|| ( Artistic GPL-2 )".
Comment 12 Martin von Gagern 2010-01-10 09:24:19 UTC
David Abbott, why have you marked this as "fixed"? I can't find the ebuild in current main portage tree CVS. I think this request should remain open until it is. If you are of a different opinion, at least a comment explaining your motivation would have been in order.
Comment 13 David Abbott (RETIRED) gentoo-dev 2010-01-10 11:55:42 UTC
(In reply to comment #12)
> David Abbott, why have you marked this as "fixed"? I can't find the ebuild in
> current main portage tree CVS. I think this request should remain open until it
> is. If you are of a different opinion, at least a comment explaining your
> motivation would have been in order.
> 
You are right I should have added a comment, The reason I closed it was the ebuild was reported to be available in the sunrise overlay and my understanding of Perl in the policy;
http://www.gentoo.org/proj/en/devrel/handbook/hb-policy-ebuild.xml
If you feel the bug was closed in error than reopen.
Comment 14 Martin von Gagern 2010-01-10 14:13:44 UTC
(In reply to comment #13)
> You are right I should have added a comment, The reason I closed it was the
> ebuild was reported to be available in the sunrise overlay

I consider sunrise a step towards the solution, but inclusion into the main portage tree as the only final "FIXED" solution.

> and my understanding of Perl in the policy;
> http://www.gentoo.org/proj/en/devrel/handbook/hb-policy-ebuild.xml

I argued that point in comment #8: it's adding functionality to existing ebuilds and can't be handled by g-cpan.

> If you feel the bug was closed in error than reopen.

Doing so.
Comment 15 Thomas Sachau gentoo-dev 2014-12-14 13:39:12 UTC
The ebuild in sunrise was outdated and unmaintained, so it got removed.
Comment 16 Martin von Gagern 2014-12-14 20:38:34 UTC
Yes. The original ebuild was mine. I no longer have access to the setup (a kerberized ldap server) where I originally had needed that module. So I couldn't test and updates to the ebuild, and even more importantly, I couldn't compare it against the non-“-server” version of Authe-SASL-Cyrus which has been updated since, is now at 0.13 as well, MIGHT support all I needed, and SHOULD be installable via g-cpan.
For details see http://search.cpan.org/~adamson/Authen-SASL-Cyrus/

If anyone has interest into bringing this into the main portage tree, let me know and I may make an effort to help towards a solution. As it stands, I have no urgent need of this module at this time, and having ebuilds sit in sunrise just to rot isn't worth my effort.
Comment 17 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-12-14 21:54:34 UTC
It's not needed for main tree for now.