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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>>: > >> On Jul 11, 2017, at 7:07 PM, Ming Liu <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>>: >> 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, [email protected] >> > <mailto:[email protected]> wrote: >> > >> > From: Ming Liu <[email protected] >> > <mailto:[email protected]>> >> > >> > Term::ReadKey - A perl module for simple terminal control. >> > >> > It's being strongly recommended by po4a. >> > >> > Signed-off-by: Ming Liu <[email protected] >> > <mailto:[email protected]>> >> > --- >> > .../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 >> > [email protected] >> > <mailto:[email protected]> >> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> > <http://lists.openembedded.org/mailman/listinfo/openembedded-devel> >> >> > > -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
