NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
agreed (Score:2)
I.e. ask dpkg, ask rpm, ask Windows installation machinery/registry, etc. whether this external application/library/developer SDK has been installed, etc. In itself that is not very hard: packaging tool specific plugings (query/install/uninstall) and then a large database of mappings (what is this package called under this packaging tool, and how is this package distributed
Re:agreed (Score:1)
I find this odd though, because I've never seen any of this.
Based on what was uploaded to CPAN, I had come to see Alien:: as "We need this one specific thing really bad, so any evil thing you have to, just get it installed".
I never really saw it as something that co-ordinates with various platform-specific backends.
If so, I would have expected some to see some sort of Install::Binary::Driver::DebianApt type structure be implemented somewhere that the Alien:: module does a build_requires: dependency on... some combination of platform detection and platform-specific drivers.
Not this current situation where everything is lumped into the Alien:: module, which seems to be to appropriate for last-resort installation, but entirely inappropriate for large scale rollout.
So how did your original concept get turned so backwards?
Reply to This
Parent
Re: (Score:2)
So how long have you been around this community, anyway?
That was the idea as I remember it. Maybe I didn't communicate it clearly enough. Maybe some other idea was thrown around that stuck more in people's minds. Maybe I should have followed up on the idea to produce actual implementations so that there would have been a precedent. I don't know.
But I still think it's a good idea. Instead of trying to be essentially