I'll attach a patch that fixes a few problems in the Mail-SpamAssassin ebuild. This patch is made for 2.55 (and tested on that version), but it should apply to all versions of the 2.5x ebuilds, and fixes the same bugs in all of them. The biggest problem is that the sa-learn script has the wrong path for the perl library dir. This is because the ebuild does not use the build procedure that is used in the rpm spec file that comes with spamassassin, resulting in two sed commands being needed to kludge the library paths. Since that only fixes 2 of the 3 installed files in /usr/bin, it's not the best solution. The other problem I saw was that the comments in all the *.cf files refer to a directory that has the build dir prefix, which could be confusing for a user trying to find the information that is being referenced in the comments. The fix for the binaries is to switch over to doing the compile using a different PREFIX than that which is used for the configure/install phases. Complicating things is that the MakeMaker package has apparently changed how it sets the SITEPREFIX dir in the generated Makefile -- it is no longer set to '${PREFIX)', but to an expanded path. In order for the compile-time setting of the PREFIX to have its desired effect, I restored this variable to the unexpanded value during the configuration (an alternate fix would be to have the compile stage set all the INSTALLSITE* vars that depend on SITEPREFIX, but this seemed like a less elegant fix for the (admittedly weird) spamassassin build process. With this fix in place, the 2 sed kludges are no longer needed. The fix for the *.cf files is simply to remove the myinst setting since it is not proper to set the LOCAL_RULES_DIR to a path that includes the build dir (and the PKG_LOCAL_RULES_DIR (which does include the build dir is already set correctly).
Created attachment 12201 [details, diff] Fix some bugs in the 2.5x ebuilds Apply this patch to at least 2.55, but it also fixes 2.54, 2.53, 2.52, and 2.50 (though 2.50 would need to be hand-patched, and this buggy release (buggy in the source tar) should probably just be removed).
I suppose I should also mention why I removed the ${myinst} from the myinst var and the ${myconf} from the myconf var. When I was running "ebuild --debug ..." to test out the ebuild process, I noticed that all the variables were getting set multiple times. Removing these old-var references got rid of the duplicates.
This patch is still missing some of the required perl module deps. I'll take a look at it in a few, it's on my list. Why did you change the myconf line? does that patch run inside a sandbox? the original myconf maintained the inherited myconf from the perl-module eclass, which is how a perl module is built within the confines of the sandbox.
As I mentioned in comment 2, I removed the ${myconf} because it was causing duplicate entries. I normally run with "usersandbox" set, so I am using sandboxing, but in combination with userpriv builds. I did try it with only "sandbox" set, though, and the results were the same. When I run "emerge --debug", here's what my version of the ebuild outputs for the Makefile.PL line: perl Makefile.PL INST_PREFIX=/usr 'SITEPREFIX=$(PREFIX)' INST_SYSCONFDIR=/etc SYSCONFDIR=/big/tmp/portage/Mail-SpamAssassin-2.55/image//etc RUN_RAZOR1_TESTS=n RUN_RAZOR2_TESTS=n PREFIX=/big/tmp/portage/Mail-SpamAssassin-2.55/image//usr Note that the PREFIX define was added by the eclass. With the ${myconf} present, I get lots of duplicates of OUR variables (the PREFIX is not duplicated): perl Makefile.PL INST_PREFIX=/usr 'SITEPREFIX=$(PREFIX)' INST_SYSCONFDIR=/etc SYSCONFDIR=/big/tmp/portage/Mail-SpamAssassin-2.55/image//etc RUN_RAZOR1_TESTS=n RUN_RAZOR2_TESTS=n INST_PREFIX=/usr 'SITEPREFIX=$(PREFIX)' INST_SYSCONFDIR=/etc SYSCONFDIR=/big/tmp/portage/Mail-SpamAssassin-2.55/image//etc RUN_RAZOR1_TESTS=n RUN_RAZOR2_TESTS=n INST_PREFIX=/usr 'SITEPREFIX=$(PREFIX)' INST_SYSCONFDIR=/etc SYSCONFDIR=/big/tmp/portage/Mail-SpamAssassin-2.55/image//etc RUN_RAZOR1_TESTS=n RUN_RAZOR2_TESTS=n PREFIX=/big/tmp/portage/Mail-SpamAssassin-2.55/image//usr I have not tried to look into this to see if this is a portage problem -- I just got rid of the dups and was hoping that someone more knowedgable in portage would be able to comment on why this was happening and if my fix was valid or not.
I just discovered a potentially better fix for the duplicate problem: if you add these two lines to the perl-modules.eclass, the duplicates go away: myconf="" mymake="" Doing this would allow the ${myconf} and ${mymake} references to be added back into this ebuild.
Those two lines cannot be added to the perl-modules.eclass as they would break other modules that rely on the eclass. Investigating the spamassassin ebuild now, which is a customized use of the eclass anyway.
Wayne - Wasn't trying to argue with you, promise :) The -r1 of 2.55 fixes a perl depend (time::Hires isn't a depend, I checked) and attempts to address the issues you've brought up. I tried your changes to myconf/myinst/mymake, but still had the temporary portage dir show up in the .cf's (and the scripts, etc). I'm afraid the nasty sed's need to remain, at least for a few more days. On the up side, the perl Makefile.PL line is much cleaner now (no more dups) and the end resulting .cf, man, and scripts no longer contain references to /var/tmp/portage/ (or in your case, /big/tmp/portage, but you know what I mean).
Re: dependencies -- I'm glad you're checking them, as I just left them unchanged from their original value in older ebuilds (and hadn't looked at them at all). Re: perl-modules.eclass -- did you try adding the variables and notice breakage? Or assume breakage? I was just assuming that all other users of perl-modules.eclass were in the same boat as Mail-SpamAssassin and needed the same fix, but had not tested it. I just checked the PerlQt ebuild, and it exhibits the same duplicate-myconf problem. There seem to be very few ebuilds that even set the myconf variable (in the dev-perl ebuilds), so fixing this in either manner would be fairly trivial. Re: still needing sed -- I assume you must have missed one of the interlocking changes I made to the ebuild. For instance, if you didn't change perl-module_src_prep to perl-module_src_compile, it wouldn't have compiled the source with the right options. Specifically, the current ebuild calls the perl-module_src_prep routine explicitly, never calls the perl-module_src_compile routine at all, and relys on the fact that the perl-module_src_install routine builds the executables before installing them. My ebuild calls the compile class explicitly (which calls the prep eclass implicitly), and thus the scripts are extracted in the right context before the install step. Another change that is vital is the addition of the mymake variable, which makes sure that the PREFIX gets set to the real install prefix during the compile step. Finally, the SITEPREFIX=\$(PREFIX) in the myconf line is also vital, without which the mymake override would not work with a modern MakeMaker. The other changes to the myconf variable came from the rpm build process. I also advocated the removal of the override of the LOCAL_RULES_DIR variable. Its presence just results in invalid paths in the comments of the *.cf files. It looks like you've added a sed loop to fix these instead. I'll attach my merged ebuild that incorporates your DEPEND changes. If this ebuild doesn't work for you, would you be so kind as to email me the output of an "emerge --debug" run so I can see where it messes up on your system? Thanks.
Created attachment 13473 [details] Changes the prep/compile/install so that sed isn't needed Here's my suggested ebuild.
I'm willing to admit it - it works now. I tried your edits originally re: the myconf/mymake lines and was still getting the bad .cf's. Taking the full version of the ebuild you've submitted and building works now. I'm adding you to the changelog for the submission - thanks! Let me know if this can be closed out now, Mike
One last thing Wayne: regarding the perl-module.eclass. In the case of a "normal" perl module, the myconf inclusion doesn't produce duplicates. If you take a look at a normal vanilla module, such as File-Spec, you'll see that the line isn't duplicated. The issue comes in with the special ebuilds that need to inherit the perl-module eclass to fulfill internal needs, but that have extended compiling options, like SpamAssassin. We can talk outside this bug about this if you'd like, or you can submit a bug regarding that inclusiion so that we have a reference point for it, but that begins to get outside the scope of this bugs original purpose.
Good! I'm glad that the revised ebuild is now working OK. I don't believe there is anything remaining to keep this open, so feel free to close it out.
One comment on the recent DEPEND changes: I have had neither dev-perl/PodParser nor dev-perl/Time-Local installed on my system, and spamassassin has been working fine for me. Also, neither of these packages is mentioned in the INSTALL file, so I'm curious as to why they were added to the DEPEND line?
From the Makefile.PL for spamassasin. 'PREREQ_PM' => { 'ExtUtils::MakeMaker' => 5.45 *0, # we have compatibility code in build/preprocessor.pm 'File::Spec' => 0.8, 'File::Copy' => 0, 'Pod::Usage' => 0, 'HTML::Parser' => 3.0, 'Text::Wrap' => 0, 'Time::Local' => 0, 'Errno' => 0, }, Please note Time::Local and Pod::Usage.
Both of those functions come standard in perl 5.8 (and the spamassassin INSTALL file mentions that Pod::Usage was standard as early as 5.6 -- I'm not sure about Time::Local). That explains why I didn't need the separate packages installed. Seems to me that these packages should be dropped from portage or marked as conflicting with perl 5.8, shouldn't they?
We still have users using perl 5.6.1. These are upgrades for both them as well as yourself. This bug is about the spamassassin ebuild and cleaning it up. I'm going to close it unless there is anything more pertaining to that clean up. I'd be happy to talk about this offline, really, but this bug is digressing from the original post (I think).
This has been incorporated and into portage.
