Front page | perl.perl5.porters |
Postings from June 2013
On Sat, Jun 1, 2013 at 3:44 AM, Kent Fredric <kentfredric@gmail.com> wrote: > There's always the usecases for that where you are > > - A (Linux)? Vendor of some kind packaging cpan into a binary dep ( debian > etc ) > - A (Linux)? Vendor of some kind who still installs stuff from source, but > using vendor toolchain instead of CPAN clients. (Gentoo) > > These cases are not really MB/P5P's concern, but its still helpful to > acknowlege they exist Agreed -- but from an end user perspective, they should be fine as long as they stick with their vendor's approach. > I don't think we can evaluate > Perl code / scrape Build.PL / META.* to answer that question reliably > either, at least, not without hard-coding a list of things to scrape for. ( > and simply scraping META.* for dependencies and trying to compare them with > our own will prove useless, because nothing in there is in a format anything > like what we have downstream ) I don't really understand how your phrased that, but suggest that you take it upon another thread (maybe on cpan-workers@perl.org) or on #toolchain on IRC. The only way to find dependencies authoritatively is to read META.json for prereqs/configure/requires -- install those -- and then run Build.PL/Makefile.PL to generate MYMETA.json and then read that. Whether you do that on the fly or do that "offline" and store the result for your platform doesn't matter, but if you don't, then you're not picking up dependencies correctly. How you translate modules into packages in your vendor system is another tricky thing -- but presumably you've got something for that already. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdgThread Previous | Thread Next