BSDPAN is not pkgng aware Fix: BSDPAN should become pkgng aware. How-To-Repeat: Install a perl module using CPAN. Later attempt to remove it. pkg delete bsdpan-.... : unknown pkg_delete bsdpan-.... : lots of error messages about converted and/or updated packages being corrupt. (portmaster saves distfiles in /var/db/pkg, but doesn't remove old installs when port is updated.) Plus pkg2ng didn't move or change anything during conversion... Not sure what safe to remove... While I can create a port of the perl module to work around this, it leaves bsdpan-Mail-SpamAssassin-Compiled... as a package that isn't registered with pkgng. For now, I'm just removing the /var/db/pkg/bsdpan- directory and the contents of /var/db/spamassassin/compiled, instead of pkg_delete before each call to sa-compile.
This bug is a blocker for my client. I'm looking for someone to fix it *soon*, and client is willing to pay. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig
I don't know where this goes, so I'll pass it to pkg@ so they can direct it to the person that needs to look at this.
bsdpan is a big hack that defeat most of the benefit of any package manager hence it has not been ported to pkg by pkg developers, now bsdpan is developed along with perl so if one his volunteering to make a bsdpan version for pkg(8) then he has to talk with perl@
There is https://github.com/infracaninophile/BSDPAN from matthew@ ? What's the status ? Do you need help ? Testers ? ... ?
That's languishing somewhere down my ToDo list I'm afraid. Not ready for testing or anything yet.
my 5 cents here. I don't see why we need BSDPAN anymore. 1. It only support ExtUtils::MakeMaker (Module::Build and Co behind doors) 2. I can't imagine why you need registered cpan modules and how pkgng must process it. Since they can only depend on lang/perl5.x). And pkgng is much more smarter then pkg_* toolkit. Let it die already.
Well, it provides a record of the files installed for the Perl module by CPAN, which makes for easier removal. Especially if its a module that shares directories with another Perl module. And, its certainly more convenient than creating a new port and submitting it and then waiting months to see if it'll get any traction. Or having portmaster wanting to delete it because it hasn't yet. Though for the specific remaining case, 'sa-compile'...since it goes outside the Perl @INC path, just deleting its directory before the compile works for me. OTOH, it was considered a nice thing when we were evaluating the possibility of mainstream use of FreeBSD servers in our datacenter. And, the question of what if we need a Perl module not in the ports tree. When we do Perl modules on our Solaris servers, I'm required to convert each and every Perl module into a Sun package file. (it should be we, but I'm the only one that seems to have the tolerance to stick with installs with more than a couple dependencies that aren't already in our package management system.) The last time was to install mimedefang, involved adding nearly 100 new packages to our package management system. Though in looking at FreeBSD, it did (finally) open the door to replacing our home grown package generation system with something ports like. Unfortunately, in a change of leadership....we're still ditching Solaris, but we're going with Ubuntu. Probably not going to be able to get ZFS into our installs....:(
BSDPAN was removed in https://svnweb.freebsd.org/ports?view=revision&revision=374844
(In reply to Andrej Zverev from comment #6) Well, it's very easy why I want it back. I have systems that require CPAN modules that are not in ports - and when I upgrade to a new perl version, being able to say "pkg_info |grep bsdpan" told me nicely which perl modules to deinstall and rebuild after upgrading all the ports based stuff. Now, I have to do that manually outside the pkg system, and can't easily clean up an installed module ("pkg_delete bsdpan-...") either. So, from a sysadmin perspective, this is a major regression in pkgng. (Whether or not bsdpan handled every corner case perfectly is certainly open for further discussion. "Just taking it away and claiming nobody needs it" is not the right answer to that, though)
(In reply to Gert Doering from comment #9) Sorry, can't help you. You can create ports for such modules and put it in your local ports tree.