From: "Jörg Krause" <jkrause@posteo.de>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 1/3] Rename package mpc to libmpc
Date: Tue, 22 Jul 2014 20:11:25 +0200 [thread overview]
Message-ID: <53CEA94D.9050403@posteo.de> (raw)
In-Reply-To: <20140722170246.GA3667@free.fr>
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
next prev parent reply other threads:[~2014-07-22 18:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-21 14:12 [Buildroot] [RFC 0/3] Rename of mpc, gmp, mpfr to libmpc, libgmp, libmpfr Jörg Krause
2014-07-21 14:12 ` [Buildroot] [RFC 1/3] Rename package mpc to libmpc Jörg Krause
2014-07-21 14:25 ` Thomas Petazzoni
2014-07-21 16:30 ` Gustavo Zacarias
2014-07-21 18:19 ` Thomas Petazzoni
2014-07-22 8:23 ` Jörg Krause
2014-07-22 10:20 ` Gustavo Zacarias
2014-07-22 17:02 ` Yann E. MORIN
2014-07-22 18:11 ` Jörg Krause [this message]
2014-07-21 14:12 ` [Buildroot] [RFC 2/3] Rename package gmp to libgmp Jörg Krause
2014-07-21 14:12 ` [Buildroot] [RFC 3/3] Rename package mpfr to libmpfr Jörg Krause
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53CEA94D.9050403@posteo.de \
--to=jkrause@posteo.de \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox