| Message ID | 1405951937-21226-2-git-send-email-jkrause@posteo.de |
|---|---|
| State | Rejected |
| Headers | show |
Dear Jörg Krause, On Mon, 21 Jul 2014 16:12:15 +0200, Jörg Krause wrote: > diff --git a/package/mpc/mpc.mk b/package/libmpc/libmpc.mk > similarity index 53% > rename from package/mpc/mpc.mk > rename to package/libmpc/libmpc.mk > index 81ee5f0..766e113 100644 > --- a/package/mpc/mpc.mk > +++ b/package/libmpc/libmpc.mk > @@ -1,15 +1,15 @@ > ################################################################################ > # > -# mpc > +# libmpc > # > ################################################################################ > > -MPC_VERSION = 1.0.2 > -MPC_SITE = $(BR2_GNU_MIRROR)/mpc > -MPC_LICENSE = LGPLv3+ > -MPC_LICENSE_FILES = COPYING.LESSER > -MPC_INSTALL_STAGING = YES > -MPC_DEPENDENCIES = gmp mpfr > +LIBMPC_VERSION = 1.0.2 > +LIBMPC_SITE = $(BR2_GNU_MIRROR)/mpc > +LIBMPC_LICENSE = LGPLv3+ > +LIBMPC_LICENSE_FILES = COPYING.LESSER > +LIBMPC_INSTALL_STAGING = YES > +LIBMPC_DEPENDENCIES = libgmp libmpfr Did you actually test this? With the package named "mpc", we didn't had to define MPC_SOURCE, as it is inferred from the package name. If the package is named "libmpc", then surely, there needs to be a LIBMPC_SOURCE specification. That being said, I would prefer to find a different name for the mpc package (mpd client) rather than renaming existing packages. Best regards, Thomas
On 07/21/2014 11:25 AM, Thomas Petazzoni wrote: > That being said, I would prefer to find a different name for the mpc > package (mpd client) rather than renaming existing packages. +1 Renaming it is potentially very problematic for people that use mpc (multiprecision library) for their own projects, mpc would be a completely different thing now and we can't make it legacy either since there would be a new mpc. Just call it mpclient and use a different bool IMHO. Regards.
Hello, On Mon, 21 Jul 2014 13:30:03 -0300, Gustavo Zacarias wrote: > On 07/21/2014 11:25 AM, Thomas Petazzoni wrote: > > > That being said, I would prefer to find a different name for the mpc > > package (mpd client) rather than renaming existing packages. > > +1 > Renaming it is potentially very problematic for people that use mpc > (multiprecision library) for their own projects, mpc would be a > completely different thing now and we can't make it legacy either since > there would be a new mpc. > Just call it mpclient and use a different bool IMHO. Agreed. "mpclient" sounds like a good alternative. Thanks, Thomas
Dear Thomas, Dear Gustavo, On 07/21/2014 08:19 PM, Thomas Petazzoni wrote: > Hello, > > On Mon, 21 Jul 2014 13:30:03 -0300, Gustavo Zacarias wrote: >> On 07/21/2014 11:25 AM, Thomas Petazzoni wrote: >> >>> That being said, I would prefer to find a different name for the mpc >>> package (mpd client) rather than renaming existing packages. >> +1 >> Renaming it is potentially very problematic for people that use mpc >> (multiprecision library) for their own projects, mpc would be a >> completely different thing now and we can't make it legacy either since >> there would be a new mpc. >> Just call it mpclient and use a different bool IMHO. > Agreed. "mpclient" sounds like a good alternative. okay, I understand that renaming is potentially problematic. But the package mpc is not a dependency for any package. gmp is a dependency for eight packages, and mpfr for one. Looking at Debian, Arch, and Fedora, these packages are all named libmpc, libgmp, and libmpfr. I liked the idea of having consistent package names. And if I am searching for mpc in the menuconfig I find the multiprecision library as libmpc and the mpd client as mpc. So it's not to difficult to find the right package. There are dozen of clients for mpd. At least calling the package "mpclient" will show my the package when searching for "mpc" in the menuconfig. Btw, is there any rule for duplicate names? Best regards Jörg
On 07/22/2014 05:23 AM, Jörg Krause wrote: Hello. > okay, I understand that renaming is potentially problematic. But the > package mpc is not a dependency for any package. gmp is a dependency for > eight packages, and mpfr for one. > > Looking at Debian, Arch, and Fedora, these packages are all named > libmpc, libgmp, and libmpfr. I liked the idea of having consistent > package names. And if I am searching for mpc in the menuconfig I find > the multiprecision library as libmpc and the mpd client as mpc. So it's > not to difficult to find the right package. Well in gentoo mpfr is mpfr and so no, not prepended by lib since there are categories which allows for duplicate naming. The problem is if someone uses mpc in their custom packages, there's no easy way of warning about the rename. > There are dozen of clients for mpd. At least calling the package > "mpclient" will show my the package when searching for "mpc" in the > menuconfig. > > Btw, is there any rule for duplicate names? Yes that was the idea, mpclient doesn't sound right, but search works, we could as well use mpcclient for example. There's no rule for duplicates, best effort comes to mind. Regards.
Gustavo, Jörg, All, On 2014-07-22 07:20 -0300, Gustavo Zacarias spake thusly: > On 07/22/2014 05:23 AM, Jörg Krause wrote: > > okay, I understand that renaming is potentially problematic. But the > > package mpc is not a dependency for any package. gmp is a dependency for > > eight packages, and mpfr for one. > > > > Looking at Debian, Arch, and Fedora, these packages are all named > > libmpc, libgmp, and libmpfr. I liked the idea of having consistent > > package names. And if I am searching for mpc in the menuconfig I find > > the multiprecision library as libmpc and the mpd client as mpc. So it's > > not to difficult to find the right package. > > Well in gentoo mpfr is mpfr and so no, not prepended by lib since there > are categories which allows for duplicate naming. > The problem is if someone uses mpc in their custom packages, there's no > easy way of warning about the rename. Not only that, but users re-using a .config from a previous Buildroot version would also be a problem. We can not have a legacy symbol for mpc as our previous "libmpc" and a new symbol for mpc as the new package "mpd client", since that would be the same symbol. So, I agree with Thomas here: we should not rename the current mpc, and find an alternate name for the new mpc. > > There are dozen of clients for mpd. At least calling the package > > "mpclient" will show my the package when searching for "mpc" in the > > menuconfig. > Yes that was the idea, mpclient doesn't sound right, but search works, > we could as well use mpcclient for example. Or mpd-mpc. > > Btw, is there any rule for duplicate names? > There's no rule for duplicates, best effort comes to mind. Untold policy is: first come, first served. ;-) Regards, Yann E. MORIN.
Dear all, On 07/22/2014 07:02 PM, Yann E. MORIN wrote: > Gustavo, Jörg, All, > > On 2014-07-22 07:20 -0300, Gustavo Zacarias spake thusly: >> On 07/22/2014 05:23 AM, Jörg Krause wrote: >>> okay, I understand that renaming is potentially problematic. But the >>> package mpc is not a dependency for any package. gmp is a dependency for >>> eight packages, and mpfr for one. >>> >>> Looking at Debian, Arch, and Fedora, these packages are all named >>> libmpc, libgmp, and libmpfr. I liked the idea of having consistent >>> package names. And if I am searching for mpc in the menuconfig I find >>> the multiprecision library as libmpc and the mpd client as mpc. So it's >>> not to difficult to find the right package. >> Well in gentoo mpfr is mpfr and so no, not prepended by lib since there >> are categories which allows for duplicate naming. >> The problem is if someone uses mpc in their custom packages, there's no >> easy way of warning about the rename. > Not only that, but users re-using a .config from a previous Buildroot > version would also be a problem. > > We can not have a legacy symbol for mpc as our previous "libmpc" and a > new symbol for mpc as the new package "mpd client", since that would be > the same symbol. > > So, I agree with Thomas here: we should not rename the current mpc, and > find an alternate name for the new mpc. Okay, you all convinced me :-) We leave it as it is. > >>> There are dozen of clients for mpd. At least calling the package >>> "mpclient" will show my the package when searching for "mpc" in the >>> menuconfig. >> Yes that was the idea, mpclient doesn't sound right, but search works, >> we could as well use mpcclient for example. > Or mpd-mpc. This was my idea, too. I think I will choose this name. > >>> Btw, is there any rule for duplicate names? >> There's no rule for duplicates, best effort comes to mind. > Untold policy is: first come, first served. ;-) Damn, so I am much to late ;-) Thanky you all for the discussion! So I think we can close this topic now. Best regards Jörg
diff --git a/package/Config.in b/package/Config.in index 703fd3d..9370d7c 100644 --- a/package/Config.in +++ b/package/Config.in @@ -838,6 +838,7 @@ menu "Other" source "package/libgc/Config.in" source "package/libglib2/Config.in" source "package/libical/Config.in" + source "package/libmpc/Config.in" source "package/libnspr/Config.in" source "package/libpfm4/Config.in" source "package/libplist/Config.in" @@ -855,7 +856,6 @@ menu "Other" source "package/libuv/Config.in" source "package/linux-pam/Config.in" source "package/lttng-libust/Config.in" - source "package/mpc/Config.in" source "package/mpfr/Config.in" source "package/msgpack/Config.in" source "package/mtdev2tuio/Config.in" diff --git a/package/mpc/Config.in b/package/libmpc/Config.in similarity index 87% rename from package/mpc/Config.in rename to package/libmpc/Config.in index 8377013..e4b5e01 100644 --- a/package/mpc/Config.in +++ b/package/libmpc/Config.in @@ -1,5 +1,5 @@ -config BR2_PACKAGE_MPC - bool "mpc" +config BR2_PACKAGE_LIBMPC + bool "libmpc" select BR2_PACKAGE_MPFR select BR2_PACKAGE_GMP help diff --git a/package/mpc/mpc.mk b/package/libmpc/libmpc.mk similarity index 53% rename from package/mpc/mpc.mk rename to package/libmpc/libmpc.mk index 81ee5f0..766e113 100644 --- a/package/mpc/mpc.mk +++ b/package/libmpc/libmpc.mk @@ -1,15 +1,15 @@ ################################################################################ # -# mpc +# libmpc # ################################################################################ -MPC_VERSION = 1.0.2 -MPC_SITE = $(BR2_GNU_MIRROR)/mpc -MPC_LICENSE = LGPLv3+ -MPC_LICENSE_FILES = COPYING.LESSER -MPC_INSTALL_STAGING = YES -MPC_DEPENDENCIES = gmp mpfr +LIBMPC_VERSION = 1.0.2 +LIBMPC_SITE = $(BR2_GNU_MIRROR)/mpc +LIBMPC_LICENSE = LGPLv3+ +LIBMPC_LICENSE_FILES = COPYING.LESSER +LIBMPC_INSTALL_STAGING = YES +LIBMPC_DEPENDENCIES = libgmp libmpfr $(eval $(autotools-package)) $(eval $(host-autotools-package))
Signed-off-by: Jörg Krause <jkrause@posteo.de> --- package/Config.in | 2 +- package/{mpc => libmpc}/Config.in | 4 ++-- package/{mpc/mpc.mk => libmpc/libmpc.mk} | 14 +++++++------- 3 files changed, 10 insertions(+), 10 deletions(-) rename package/{mpc => libmpc}/Config.in (87%) rename package/{mpc/mpc.mk => libmpc/libmpc.mk} (53%)