You are not logged in.

#1 2012-08-12 12:05:11

Athaba
Member
Registered: 2005-12-24
Posts: 3

[Proposal] Perl PKGBUILDs: Use MetaCPAN and no testing

Hello,

I want to propose a new guideline for Perl packages. These are two independent points and I understand the latter will probably be rejected, but please have a look on them independently.

My first proposal is that the default mirror for Perl packages available on CPAN should be MetaCPAN. This should be for both the official website (if there is no other) and the (primary) mirror. MetaCPAN is modern and fast-syncing. Downloads from there are also usually really fast. It became a heavily advertised alternative to the old cpan.org and really is preferred by pretty much everyone that knows about it. I therefor think it would be a good idea to adjust the /usr/share/pacman/PKGBUILD-perl.proto to use MetaCPAN.

My other proposal is not using tests. There are a number of reasons for that. First and foremost, if a package works for the author of a PKGBUILD it is supposed to work for everyone. Tests these days are mainly used by CPAN Testers, who wouldn't use packages anyway, but already make sure archives from CPAN work nicely on Arch Linux and other distributions. This causes it to be a huge waste of CPU cycles, but also other resources. Many packages depend on others solely for the purpose of testing them. Also, usually when there is an author of a PKGBUILD it will be used by that author anyway, giving it a much better test, making sure it is working (maybe despite of tests failing for other reasons, being buggy). While I agree testing is important (I am a CPAN Tester) I don't think it is the job of someone wanting to install a package from AUR or in general building it. Now, this isn't part of the .proto file anyway, but it is for example part of the Wiki (and even worse outside of the check phase). I'd change it (or maybe mention that it maybe doesn't make so much sense), but I want to hear what the opinion on this matter is. Another opinion would of course maybe be the integration of CPAN Testers into the whole process (maybe even in makepkg.conf, just package singning), even though I doubt it would really be worth the effort nor the right place for it.

Related to this: http://www.openswartz.com/2012/01/31/st … n-install/ (also see the comments)

Last edited by Athaba (2012-08-12 12:08:21)

Offline

#2 2012-08-12 12:14:37

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,835

Re: [Proposal] Perl PKGBUILDs: Use MetaCPAN and no testing

You might not reach the right audience here, so post this a feature request in the bugtracker.

Offline

#3 2012-08-14 17:00:34

juster
Forum Fellow
Registered: 2008-10-07
Posts: 195

Re: [Proposal] Perl PKGBUILDs: Use MetaCPAN and no testing

I found this post when doing a search for "perl" as I sometimes do. I hope it is not too late to make a response. These are interesting proposals.

MetaCPAN is a much more attractive website than the venerable search.cpan.org or even kobesearch. I am something of a plebeian compared to most Archers so I waited several months before using it in my packages as the "url" homepage. So far it has worked well, though it has a few kinks. Ironically, a recurring bug causes the "common::sense" module to not appear in its listings.

I hesitate to use MetaCPAN as a download mirror. search.cpan.org uses HTTP 302 redirects to spread downloads across many different mirrors across the world. The goal is to forward the client to a geographically closer server. Downloads from metacpan.org only use metacpan's own servers. This begs the question of whether metacpan.org is a faster file server for everyone or is it faster for merely you and I?

Testing is a much pricklier subject. In the blog post you link to, Jason Swartz refers to Rolsky's "The Real Problem with Dependencies". Dave Rolsky notes how debian packages install cleanly and do not run tests on install. He suggests that CPAN dists follow suite. He ignores the fact that tests are run when a debian package is built and are not foregone altogether. This is an important distinction that is missing from your proposal.

This distinction between binary packages, such as Arch uses, and source distributions is very important because of the freestyle process each CPAN dist uses to configure and install itself. The Makefile.PL script has full reign to add or remove requirements and even modify the source code on the fly before installation. The point is that the user may have modules or libraries installed the package author did not. These extras change the configuration of the module itself and can result in broken software.

Keep in mind some people might use the prototype PKGBUILD for a template of official packages. Missing tests in official packages would be kind of pitiful. Testing once for the supposed benefit of all package users is a small price to pay. I think you were only talking about source PKGBUILDs. I'm not trying to detract from your proposal but encouraging you be more specific.

Source PKGBUILDs are the best candidate but because of the wild variability of the configuration process I mentioned above I consider them much more treacherous than built packages. Yet again, in the end, what does it really matter? Sometimes tests give false positives. Sometimes I even told AUR package commentators to skip tests because I was too lazy to read through source code. Sometimes failed tests helped to show me a conflict with a user's installed packages. So really it boils down to giving users what they want, not what they need. Something ArchLinux is not known for.

The biggest problem with your proposal is how to mimic --notest by default? By suggesting editing the PKGBUILD prototype you imply that we comment out "make test" or "./Build test" or, dare I say it, leave out the check() function altogether. This is extremely inconvenient for "power users" who prefer tests. This is not the same as what Swartz or Miyagawa suggest. They suggest changing the default, but still allowing people to enable tests easily.

You are narrowing your perspective too much. Your only real option, if you are following the suggestion of the blog post as you suggest, would be to enable makepkg's --skiptest by default. That might be a tough sell.

Offline

#4 2012-08-14 18:32:53

Athaba
Member
Registered: 2005-12-24
Posts: 3

Re: [Proposal] Perl PKGBUILDs: Use MetaCPAN and no testing

juster wrote:

I hesitate to use MetaCPAN as a download mirror. search.cpan.org uses HTTP 302 redirects to spread downloads across many different mirrors across the world. The goal is to forward the client to a geographically closer server. Downloads from metacpan.org only use metacpan's own servers. This begs the question of whether metacpan.org is a faster file server for everyone or is it faster for merely you and I?

I agree. Something in between would be better. The problem is that there are many really slow CPAN mirrors too. For example there are some local universities, that I have a relatively good (as in path length/being on the same network) connection to, but still are kinda slow compared to other mirrors, even if they are on the other side of the world. I am not currently sure, whether MetaCPAN was only a single mirror. I think the CPAN Testers mirror actually spreads it across some rather fast (not just fast syncing) mirrors, but I could be mistaken. Weill see, if I find something.

But I agree. We maybe shouldn't all use the very same server in general.

Testing is a much pricklier subject. In the blog post you link to, Jason Swartz refers to Rolsky's "The Real Problem with Dependencies". Dave Rolsky notes how debian packages install cleanly and do not run tests on install. He suggests that CPAN dists follow suite. He ignores the fact that tests are run when a debian package is built and are not foregone altogether. This is an important distinction that is missing from your proposal.

Well, yeah. I kinda wished there was like "I am a package developer option" that enables tests, that maybe for all packages enables/disables the check phase, but is off by default. I don't know, maybe there could also be an always-check or never-check often, if you don't want to have that for all packages, but that would maybe just add to complexity. Still, is it a good idea when every user per default runs the check phase of a package, just because of using yaourt to get access to more packages?

About the fact that packages usually get checked at build time. That's true. That's why such a "I am a developer option" may be a good idea. However, one also has to see that thanks to CPAN Testers the support on a "normal" Linux distribution like Arch Linux usually is really good. There are a number of Perl developers that use Arch, so even when they appear they are found rather quickly, even if the usual AUR user wouldn't test every package that gets installed.

I don't know what's the best option, but checking something all the time by every user that installs it, for everyone package update (not just releases) when the package provides test seems like a waste of resources.

This distinction between binary packages, such as Arch uses, and source distributions is very important because of the freestyle process each CPAN dist uses to configure and install itself. The Makefile.PL script has full reign to add or remove requirements and even modify the source code on the fly before installation. The point is that the user may have modules or libraries installed the package author did not. These extras change the configuration of the module itself and can result in broken software.

The same is true however for every Linux distribution that comes with binaries. That's because a lot of modules check for optional dependencies at runtime. In fact Arch Linux always built on that for many packages. I don't think it should be a bigger problem for Perl packages when it isn't for others. Or am I mistaken somehow?

The biggest problem with your proposal is how to mimic --notest by default? By suggesting editing the PKGBUILD prototype you imply that we comment out "make test" or "./Build test" or, dare I say it, leave out the check() function altogether. This is extremely inconvenient for "power users" who prefer tests. This is not the same as what Swartz or Miyagawa suggest. They suggest changing the default, but still allowing people to enable tests easily.

Making better use of the check phase, like suggested above would be a good option I think.

You are narrowing your perspective too much. Your only real option, if you are following the suggestion of the blog post as you suggest, would be to enable makepkg's --skiptest by default. That might be a tough sell.

Well, it's a reason why I want discuss things. I am aware of the potential problems this causes. That's why I want to discuss them. I always want to hear some real life experiences, because I just don't know how many of these problems are actual real life problems, that happen. I just never had a problem with a package where a test (by a user) showed me much more than a problem with missing dependencies and installing packages to my (user local) perlbrew install, which is something one would probably consider much more unstable works pretty well. If you think the price is small enough that's nice.

I also kinda wish, if everyone did package tests anyway they'd be reported if was for something else than missing dependencies. However, I know this probably isn't really reasonable to implement either (to happen automatically), because it's often just a problem with the PKGBUILD and shouldn't really interest CPAN authors.

Last edited by Athaba (2012-08-14 18:43:04)

Offline

Board footer

Powered by FluxBB