Comments for yellowjacketgnuhttps://yellowjacketgnu.wordpress.com
The source is open, so use it, damnitTue, 07 May 2013 20:38:37 +0000hourly1http://wordpress.com/Comment on Perl – An Apology and a retraction by Max Lybberthttps://yellowjacketgnu.wordpress.com/2013/05/07/perl-an-apology-and-a-retraction/comment-page-1/#comment-22
Tue, 07 May 2013 20:38:37 +0000http://yellowjacketgnu.wordpress.com/?p=66#comment-22In this particular case, the RPM was wrong about this particular dependency. Your larger complaint about developers failing to keep a handle on their dependencies is perfectly valid; it’s just not Perl-specific.

The problem of ever-growing dependencies will only get worse until it becomes common to refuse to install things simply because the list of dependencies is too long (and that is a perfectly valid approach; *often* a long list of dependencies is really a symptom of not using a platform’s strengths).

]]>Comment on Perl – An Apology and a retraction by alicewonder32https://yellowjacketgnu.wordpress.com/2013/05/07/perl-an-apology-and-a-retraction/comment-page-1/#comment-21
Tue, 07 May 2013 16:35:53 +0000http://yellowjacketgnu.wordpress.com/?p=66#comment-21I’m kind of a hypocrite because non-binary PEAR packages I manage with PEAR, not RPM (but binary PECL modules I do prefer RPM) and TeXLive – I install from tug.org and don’t use RPM – I manage it via tlmgr.

But neither php nor texlive are used by other applications the way perl is. TeXLive is sometimes used to build documentation, but that’s about it. php – there is a cli binary but it’s pretty much only used for cgi stuff, you can write stuff in it for non web services but there are better languages for OS level scripting (such as perl and python) – so having what is provided by php-pear packages and TeXLive packages known to RPM isn’t quite as important.

]]>Comment on Perl – An Apology and a retraction by LJhttps://yellowjacketgnu.wordpress.com/2013/05/07/perl-an-apology-and-a-retraction/comment-page-1/#comment-20
Tue, 07 May 2013 16:28:30 +0000http://yellowjacketgnu.wordpress.com/?p=66#comment-20You’re not wrong. I just find it interesting that one of the great strengths of Perl- CPAN – which enables anybody to share software – is an object of complaint.

What I find most interesting about CPAN abundance, is that if there are several modules that solve the same problem, they often solve it in very different ways, and to me that means that one of them might solve it in a way that I would have solved it if I had to write it myself, and the way I like it solved might not be the way you like it solved. So for an investment of an hour of research, I save days of coding and testing, and I find the implementation that *feels right* to me.

I understand the desire to use RPM (et. al.) to manage dependencies. That’s what cpan clients to for Perl.
It would be wonderful if cpan clients could get smart enough to use OS-level package managers to insure that prerequisites are installed, and it would be pretty awesome if those package managers would learn how to interact with CPAN to let CPAN manage Perl.

What we have at present, is a situation where deployment/production support people want to dictate software development practice (“stop reusing code, it’s too messy and makes work for us”), because they have a pre-made solution to deployment, which means they don’t have to give it any consideration. It’s all about what’s easiest for them only. This is very similar to organizations who say that you can only use the version of perl that ships with the operating system, because they don’t want to have to expend effort (and budget) on other people’s stuff. [but I’m not bitter]. [and yes, I am apparently expected to turn my web app into an RPM so it can be lobbed over the wall for deployment by people whose job does not involve supporting the app, but just installing it – but I’m not bitter.]

]]>Comment on Perl – An Apology and a retraction by alicewonder32https://yellowjacketgnu.wordpress.com/2013/05/07/perl-an-apology-and-a-retraction/comment-page-1/#comment-19
Tue, 07 May 2013 15:53:27 +0000http://yellowjacketgnu.wordpress.com/?p=66#comment-19Well, some of the modules are very closely related and really could be put into the same source tarball, as it doesn’t really make sense to have them without each other.

When using yum on a fedora system (yum provides, yum update, etc.) and it has to download the headers, it can take a little while just because of the sheer number of packages – having 6 different RPMs for modules that really could be in a single RPM from a single source tarball, maybe in the grand scheme of things it doesn’t make a difference, but I think there could be some adjustments made to how perl modules are grouped in CPAN.

But that’s minor. The dependency bloat I complained about is looking like a Fedora thing, some packagers using BuildRequires (and possibly explicit Requires) that aren’t real.

]]>Comment on Perl – An Apology and a retraction by LJhttps://yellowjacketgnu.wordpress.com/2013/05/07/perl-an-apology-and-a-retraction/comment-page-1/#comment-18
Tue, 07 May 2013 15:45:27 +0000http://yellowjacketgnu.wordpress.com/?p=66#comment-18> With perl, there are just far too many perl modules.

Devo said it best, many years ago:

Freedom of choice, that’s what you got.
Freedom from choice, that’s what you want.

]]>Comment on People Hate Perl by alicewonder32https://yellowjacketgnu.wordpress.com/2013/04/30/people-hate-perl/comment-page-1/#comment-17
Tue, 07 May 2013 10:10:32 +0000http://yellowjacketgnu.wordpress.com/?p=57#comment-17OK – just did a test where I removed perl-Test-Base and it does build without it, so that appears to be a bogus BuildRequires that a fedora packager put in the spec file in order to pull in the real requirements. Gaw.
]]>Comment on People Hate Perl by alicewonder32https://yellowjacketgnu.wordpress.com/2013/04/30/people-hate-perl/comment-page-1/#comment-16
Tue, 07 May 2013 10:02:29 +0000http://yellowjacketgnu.wordpress.com/?p=57#comment-16Test::Base is in the BuildRequires for WWW::Curl in Fedora and when attempting to build the rpm without it, it failed tests resulting in a failed build. I suppose I could have skipped the %check section and probably been fine, since it passed the tests when Test::Base was installed (and Test::Base certainly isn’t required by the module itself) but Test::Base was required to successfully run the check target.

Perhaps the META.yml is not up to date?

]]>Comment on People Hate Perl by daximhttps://yellowjacketgnu.wordpress.com/2013/04/30/people-hate-perl/comment-page-1/#comment-15
Tue, 07 May 2013 09:56:56 +0000http://yellowjacketgnu.wordpress.com/?p=57#comment-15Hi. I am both a Perl developer and an OBS user and I am knowledgable about the Perl toolchain and RPM packaging. I can’t even reproduce your openssl tsget → WWW::Curl dep problem. Contrary to what you say, it does *not* depend on Test::Base. Proof: http://search.cpan.org/dist/WWW-Curl/META.yml and there isn’t any mention of Test::Base in all of the source of the WWW-Curl distribution, either. Further correction: Larry does not maintain Perl5 for many years anymore, perl5-porters do.

You wrote a rant completely devoid of any useful information – it’s just your interpretation of what you’re seeing, without naming cold hard facts that are verifiable by someone else. That makes me wonder, are you just interested in venting and badmouthing Perl or in solving problems? I’m offering you help: irc://irc.perl.org/toolchain or mailto:daxim~~AT~~cpan.org

]]>Comment on People Hate Perl by Max Lybberthttps://yellowjacketgnu.wordpress.com/2013/04/30/people-hate-perl/comment-page-1/#comment-14
Tue, 07 May 2013 06:25:01 +0000http://yellowjacketgnu.wordpress.com/?p=57#comment-14I’m impressed, then. Given the amount of work involved in creating the packages, I wasn’t expecting you to go through the trouble to create updated packages later when bug fixes are available. If you actually pull it off, my hat’s off to you.
]]>Comment on People Hate Perl by alicewonder32https://yellowjacketgnu.wordpress.com/2013/04/30/people-hate-perl/comment-page-1/#comment-13
Tue, 07 May 2013 01:47:20 +0000http://yellowjacketgnu.wordpress.com/?p=57#comment-13Actually updating is very important to me. I was very careful in my initial perl spec file to make sure my perl platform would be compatible with perl packaging by Fedora.

That allows me to monitor Fedora updates, grab updates, and rebuild them. Automatically in most cases.

Fedora uses a pm suffix on man pages, that I don’t use, so I have to run a simple sed on the spec file to fix broken spec files that assume a pm suffix

sed -i -e 's/\(\.[1-8]\)pm\*/\1*/g' ${SPEC}

(I only run that starting with first lines number %files is on and ending with first line number %changelog appears on)

There are two ways of dealing with filtering requires and provides. One that was used in RPM 4.8 and earlier, and one after.
Fedora’s RPM infrastructure defines both and fedora spec files specify both ways, instead of checking for the RPM version and using the method that matches.

fixes that (I only run that from line number 1 through the first line %prep appears on)
That disables the old filtering method leaving only the new RPM 4.9+ method alone.

So assuming I have the proper BuildRequires – most fedora perl spec files rebuild just fine with those asjustments.

Sometimes other asjustments are needed, e.g. sometimes they do a man page iconv conversion to UTF-8 in the %install section instead of in %prep where it belongs, resulting in a pm suffix issue on the generated man page they are converting, but those cases are rare and I send a fix to the Fedora maintainer with the iconv moved into %prep where it belongs. We’ll see if they ever apply the fixes.