[oe] [meta-oe/meta-perl] [PATCH 3/8] libterm-readkey-perl: add recipe

[Tim Orling]

Understood. I now acknowledge that you did your due diligence. I guess I have some issues with Debian’s packaging of po4a, but that is for a different channel.

Thank you for thinking things through and answering my concerns.

—Tim

> On Jul 11, 2017, at 8:44 PM, Ming Liu <liu.ming50 at gmail.com> wrote:
> 
> Hi, TIm:
> 
> I also had considered splitting po4a perl modules to a sub package to follow perl module naming scheme, but I finally decided to use the same package naming as it is on debian/ubuntu distributions(just a single main package named po4a), which I think is easier to be maintained/understood by developers/users, especially for those who are comfortable with debian systems.
> 
> 
> //MIng Liu
> 
> 2017-07-12 4:51 GMT+02:00 Tim Orling <timothy.t.orling at linux.intel.com <mailto:timothy.t.orling at linux.intel.com>>:
> 
>> On Jul 11, 2017, at 7:07 PM, Ming Liu <liu.ming50 at gmail.com <mailto:liu.ming50 at gmail.com>> wrote:
>> 
>> Hi, Tim:
>> 
>> po4a is providing some perl modules and also some normal binaries, and it's named as "po4a" on debian/ubuntu distributions as well, that's why I did not take po4a-perl as its name, shouldn't we let it have a identical name as debian distributions have, to follow debian naming?
>> 
> 
> In that case the po4a recipe is unclear and too simple. I would expect to see the libraries broken out into a sub package which does follow Debian naming. There is nothing in the recipe or commit message to indicate it is NOT a standard perl package.  It will be read by non-informed users as open season to use any naming scheme they want. Hence my concern.
> 
> Just my 2 cents.
> 
> —Tim
> 
>> the best,
>> thank you 
>> 
>> 2017-07-12 0:34 GMT+02:00 Tim Orling <timothy.t.orling at linux.intel.com <mailto:timothy.t.orling at linux.intel.com>>:
>> The original po4a recipe should have been named libpo4a-perl, to follow Debian naming. Notice that every other perl module you have in DEPENDS or RRECOMMENDS __are__ following Debian naming. Please help us keep the metadata consistent in the meta-perl layer. Thank you.
>> 
>> See 4.2 in:
>> https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html <https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html>
>> 
>> 
>> > On Jul 11, 2017, at 9:44 AM, liu.ming50 at gmail.com <mailto:liu.ming50 at gmail.com> wrote:
>> >
>> > From: Ming Liu <peter.x.liu at external.atlascopco.com <mailto:peter.x.liu at external.atlascopco.com>>
>> >
>> > Term::ReadKey - A perl module for simple terminal control.
>> >
>> > It's being strongly recommended by po4a.
>> >
>> > Signed-off-by: Ming Liu <peter.x.liu at external.atlascopco.com <mailto:peter.x.liu at external.atlascopco.com>>
>> > ---
>> > .../libterm/libterm-readkey-perl_2.37.bb <http://libterm-readkey-perl_2.37.bb/>           | 36 ++++++++++++++++++++++
>> > 1 file changed, 36 insertions(+)
>> > create mode 100644 meta-perl/recipes-perl/libterm/libterm-readkey-perl_2.37.bb <http://libterm-readkey-perl_2.37.bb/>
>> >
>> > diff --git a/meta-perl/recipes-perl/libterm/libterm-readkey-perl_2.37.bb <http://libterm-readkey-perl_2.37.bb/> b/meta-perl/recipes-perl/libterm/libterm-readkey-perl_2.37.bb <http://libterm-readkey-perl_2.37.bb/>
>> > new file mode 100644
>> > index 0000000..6b76682
>> > --- /dev/null
>> > +++ b/meta-perl/recipes-perl/libterm/libterm-readkey-perl_2.37.bb <http://libterm-readkey-perl_2.37.bb/>
>> > @@ -0,0 +1,36 @@
>> > +SUMMARY = "Term::ReadKey - A perl module for simple terminal control."
>> > +DESCRIPTION = "Term::ReadKey is a compiled perl module dedicated to providing simple \
>> > +control over terminal driver modes (cbreak, raw, cooked, etc.,) support \
>> > +for non-blocking reads, if the architecture allows, and some generalized \
>> > +handy functions for working with terminals. One of the main goals is to \
>> > +have the functions as portable as possible, so you can just plug in "use \
>> > +Term::ReadKey" on any architecture and have a good likelihood of it \
>> > +working."
>> > +HOMEPAGE = "http://search.cpan.org/~jstowe/TermReadKey-${PV} <http://search.cpan.org/~jstowe/TermReadKey-$%7BPV%7D>"
>> > +SECTION = "libraries"
>> > +
>> > +LICENSE = "Artistic-1.0 | GPLv1+"
>> > +LIC_FILES_CHKSUM = "file://README;md5= <>c275db663c8489a5709ebb22b185add5"
>> > +
>> > +SRC_URI = "${CPAN_MIRROR}/authors/id/J/JS/JSTOWE/TermReadKey-${PV}.tar.gz"
>> > +
>> > +SRC_URI[md5sum] = "e8ea15c16333ac4f8d146d702e83cc0c"
>> > +SRC_URI[sha256sum] = "4a9383cf2e0e0194668fe2bd546e894ffad41d556b41d2f2f577c8db682db241"
>> > +
>> > +S = "${WORKDIR}/TermReadKey-${PV}"
>> > +
>> > +# It needs depend on native to let dynamic loader use native modules
>> > +# rather than target ones.
>> > +DEPENDS = "libterm-readkey-perl-native"
>> > +
>> > +inherit cpan
>> > +
>> > +do_configure_append () {
>> > +    # Hack the dynamic module loader so that it use native modules since it can't load
>> > +    # the target ones.
>> > +    if [ "${BUILD_SYS}" != "${HOST_SYS}" ]; then
>> > +        sed -i -e "s#-I\$(INST_ARCHLIB)#-I${STAGING_BINDIR_NATIVE}/perl-native/perl/vendor_perl/${@get_perl_version(d)}#g" Makefile
>> > +    fi
>> > +}
>> > +
>> > +BBCLASSEXTEND = "native"
>> > --
>> > 2.7.4
>> >
>> > --
>> > _______________________________________________
>> > Openembedded-devel mailing list
>> > Openembedded-devel at lists.openembedded.org <mailto:Openembedded-devel at lists.openembedded.org>
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel <http://lists.openembedded.org/mailman/listinfo/openembedded-devel>
>> 
>> 
> 
>