aboutsummaryrefslogtreecommitdiffstats
path: root/recipes/perl/libdbi-perl_1.607.bb
Commit message (Collapse)AuthorAgeFilesLines
* perl: Drop 5.8.8, bump PR in all perl recipesTom Rini2011-02-011-1/+1
| | | | | | | | | Also remove DEFAULT_PREFERENCE = -1 from 5.10.1 Acked-by: Koen Kooi <koen@openembedded.org> Acked-by: Martin Jansa <Martin.Jansa@gmail.com> Acked-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> Signed-off-by: Tom Rini <tom_rini@mentor.com>
* perl recipes: updated license from Artistic|GPLv1 to Artistic|GPLv1+Frans Meulenbroeks2010-10-241-1/+1
| | | | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
* perl: updated LICENSE; GPL -> GPLv1Frans Meulenbroeks2010-10-091-1/+1
| | | | | | | | | | | | | | perl has as license the choice between Artistic or GPLv1. see http://dev.perl.org/licenses/ so changed LICENSE = "Artistic|GPL" to LICENSE = "Artistic|GPLv1" This also applies to CPAN recipes. Typically they specify that the code is licensed under the same terms as perl so figured that the above changes would be better in most (if not all) cases (and no, I did not verify all 130 or so recipes, if you feel this is needed, be my guest) Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
* recipes: bump PR/INC_PR for packages changed in ↵Martin Jansa2010-06-101-1/+1
| | | | | | | | | | | | | | RDEPENDS/RRECOMMENDS/RSUGGESTS/RPROVIDES/RCONFLICTS/RREPLACES cleanup * only 769 from 1102 recipes were covered by automatic PR bump, list of remaining 333 recipes not using PR/INC_PR is available for manual PR add or INC_PR conversion - volunteers? http://build.shr-project.org/tests/jama/files.not.PR.bumped * just echo 'PR = "r1"' to recipes without any PR/INC_PR is not so good idea without manual check, because sometimes they rely on PR set in their .inc file and "r1" could make it go backwards Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* recipes: conform to OE packaging guidelines with RDEPENDS/RRECOMMENDSMartin Jansa2010-06-031-1/+1
| | | | | | | | | | | | | | | | | | | | * there is probably very few cases when it's needed without _${PN}, if you find one in attached patch, please enlighten me * usually we want those only for ${PN} not for all ${PACKAGES} ie ${PN}-dev, ${PN)-doc etc * there is a check for this in recipe-sanity.bclass * there is maybe few possible fixes also in bbclasses cpan-base.bbclass:RDEPENDS += "${@["perl", ""][(bb.data.inherits_class('native', d))]}" distutils-base.bbclass:RDEPENDS += "python-core" gtk-icon-cache.bbclass:RDEPENDS += "hicolor-icon-theme" image.bbclass:RDEPENDS += "${IMAGE_INSTALL} ${IMAGE_BOOT}" module.bbclass:RDEPENDS += "kernel (${KERNEL_VERSION}) update-modules" ?opie_i18n.bbclass: rdepends = bb.data.getVar("RDEPENDS", d, 1) ?opie_i18n.bbclass: bb.data.setVar('RDEPENDS_%s' % x[0].lower(), pn, d) ?opie_i18n.bbclass: bb.data.setVar('RDEPENDS', rdepends, d) rubyextension.bbclass:RDEPENDS += "ruby" Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Acked-by: Koen Kooi <k-kooi@ti.com>
* recipes: move checksums to recipes from checksums.iniMartin Jansa2010-04-121-0/+3
| | | | | | | * fetch all *.bb with patched utils.bbclass appending all checksums found only in checksums.ini to recipe Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* perl: various recipes did not have ${PV} in URI, replacedFrans Meulenbroeks2010-01-021-1/+1
|
* perl/lib*: removed most -native recipes,Frans Meulenbroeks2010-01-011-1/+3
| | | | added BBCLASSEXTEND to the non-native recipes to automatically create the native recipes
* rename packages/ to recipes/ per earlier agreementDenys Dmytriyenko2009-03-171-0/+15
See links below for more details: http://thread.gmane.org/gmane.comp.handhelds.openembedded/21326 http://thread.gmane.org/gmane.comp.handhelds.openembedded/21816 Signed-off-by: Denys Dmytriyenko <denis@denix.org> Acked-by: Mike Westerhof <mwester@dls.net> Acked-by: Philip Balister <philip@balister.org> Acked-by: Khem Raj <raj.khem@gmail.com> Acked-by: Marcin Juszkiewicz <hrw@openembedded.org> Acked-by: Koen Kooi <koen@openembedded.org> Acked-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>