Patchwork [0/1] mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS

login
register
mail settings
Submitter xin.ouyang@windriver.com
Date July 25, 2012, 7:02 a.m.
Message ID <cover.1343199345.git.Xin.Ouyang@windriver.com>
Download mbox
Permalink /patch/32965/
State New
Headers show

Pull-request

git://git.pokylinux.org/poky-contrib xouyang/master

Comments

xin.ouyang@windriver.com - July 25, 2012, 7:02 a.m.
From: Xin Ouyang <Xin.Ouyang@windriver.com>

[YOCTO #2829] 

mtools commands use cp850 as the "mtools_default_codepage", they would
use this to do some coverting tasks. 

So, add glibc-gconv-ibm850 to RDEPENDS for mtools commands to run 
correctly.




The following changes since commit 0ffb02eec2beaea27ff0ec9d3d31b0a09e675a4c:

  documentation: Updated the h6 style to use a larger font (2012-07-24 10:35:34 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xouyang/master
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xouyang/master

Xin Ouyang (1):
  mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS

 meta/recipes-devtools/mtools/mtools_3.9.9.bb  |   20 +++++++++++++++++++-
 meta/recipes-devtools/mtools/mtools_4.0.17.bb |   20 +++++++++++++++++++-
 2 files changed, 38 insertions(+), 2 deletions(-)
Cristian Iorga - July 25, 2012, 7:23 a.m.
Hello all,

For me, having the version number contained in the name of package recipe is a little bit puzzling.
For example: libpcre/libpcre_8.31.bb

Is there a solid technical reason to not have it like this?

libpcre/libpcre.bb
and inside the recipe to have a PV variable defined:
PV="8.31"

In that case, the upgrade/update process would not involve performing a "git move" operation.
In my opinion, this "git move" operation is something to be avoided, as it puzzles a little bit the versioning system and complicates the review process.

Of course, some changes in the bitbake system would be involved, but I guess would not be too complicated.
Also, there will be a volume of work to be performed for changing the name of recipes and adding the PV variable inside the recipe.
But I guess that a script could solve that, followed by some manual review.

Waiting for some feedback.

Thanks,
Cristian

Cristian Iorga
Linux Software Engineer
Open Source Technology Center
System Software Division Romania
iNET: 88451023
Koen Kooi - July 25, 2012, 10:05 a.m.
Op 25 jul. 2012, om 09:23 heeft Iorga, Cristian het volgende geschreven:

> 
> Hello all,
> 
> For me, having the version number contained in the name of package recipe is a little bit puzzling.
> For example: libpcre/libpcre_8.31.bb
> 
> Is there a solid technical reason to not have it like this?
> 
> libpcre/libpcre.bb
> and inside the recipe to have a PV variable defined:
> PV="8.31"
> 
> In that case, the upgrade/update process would not involve performing a "git move" operation.
> In my opinion, this "git move" operation is something to be avoided, as it puzzles a little bit the versioning system and complicates the review process.

git format-patch -M
Paul Eggleton - July 25, 2012, 10:09 a.m.
On Wednesday 25 July 2012 07:23:31 Iorga, Cristian wrote:
> For me, having the version number contained in the name of package recipe is
> a little bit puzzling. For example: libpcre/libpcre_8.31.bb
> 
> Is there a solid technical reason to not have it like this?
> 
> libpcre/libpcre.bb
> and inside the recipe to have a PV variable defined:
> PV="8.31"

The benefit of having PV in the recipe file name is that you can then easily 
have different recipes for different versions of the same piece of software, 
which is particularly useful when those different versions may need to be built 
slightly differently.

Cheers,
Paul
Chris Larson - July 25, 2012, 1:48 p.m.
On Wed, Jul 25, 2012 at 3:09 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday 25 July 2012 07:23:31 Iorga, Cristian wrote:
>> For me, having the version number contained in the name of package recipe is
>> a little bit puzzling. For example: libpcre/libpcre_8.31.bb
>>
>> Is there a solid technical reason to not have it like this?
>>
>> libpcre/libpcre.bb
>> and inside the recipe to have a PV variable defined:
>> PV="8.31"
>
> The benefit of having PV in the recipe file name is that you can then easily
> have different recipes for different versions of the same piece of software,
> which is particularly useful when those different versions may need to be built
> slightly differently.

It's worth noting that that can still be done by leveraging
BBVERSIONS. Not that I'm advocating that approach necessarily, but
noting that it can still be done without using multiple recipes with
version in the filename.
Saul Wold - July 26, 2012, 7:01 p.m.
On 07/25/2012 12:02 AM, xin.ouyang@windriver.com wrote:
> From: Xin Ouyang <Xin.Ouyang@windriver.com>
>
> [YOCTO #2829]
>
> mtools commands use cp850 as the "mtools_default_codepage", they would
> use this to do some coverting tasks.
>
> So, add glibc-gconv-ibm850 to RDEPENDS for mtools commands to run
> correctly.
>
>
>
>
> The following changes since commit 0ffb02eec2beaea27ff0ec9d3d31b0a09e675a4c:
>
>    documentation: Updated the h6 style to use a larger font (2012-07-24 10:35:34 +0100)
>
> are available in the git repository at:
>
>    git://git.pokylinux.org/poky-contrib xouyang/master
>    http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xouyang/master
>
> Xin Ouyang (1):
>    mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS
>
>   meta/recipes-devtools/mtools/mtools_3.9.9.bb  |   20 +++++++++++++++++++-
>   meta/recipes-devtools/mtools/mtools_4.0.17.bb |   20 +++++++++++++++++++-
>   2 files changed, 38 insertions(+), 2 deletions(-)
>
Merged into OE-Core

Thanks
	Sau!
Phil Blundell - July 26, 2012, 7:04 p.m.
On Wed, 2012-07-25 at 15:02 +0800, xin.ouyang@windriver.com wrote:
> +RDEPENDS_${PN} = "glibc-gconv-ibm850"

That will make mtools unbuildable for non-glibc configurations.  Is this
intended?

p.
Richard Purdie - July 26, 2012, 7:40 p.m.
On Wed, 2012-07-25 at 07:23 +0000, Iorga, Cristian wrote:
> For me, having the version number contained in the name of package recipe is a little bit puzzling.
> For example: libpcre/libpcre_8.31.bb
> 
> Is there a solid technical reason to not have it like this?
> 
> libpcre/libpcre.bb
> and inside the recipe to have a PV variable defined:
> PV="8.31"

FWIW, you can do that and it will just work, even today. Its just not
the convention we've "grown up" with.

> In that case, the upgrade/update process would not involve performing a "git move" operation.
> In my opinion, this "git move" operation is something to be avoided, as it puzzles a little bit the versioning system and complicates the review process.
> 
> Of course, some changes in the bitbake system would be involved, but I guess would not be too complicated.
> Also, there will be a volume of work to be performed for changing the name of recipes and adding the PV variable inside the recipe.
> But I guess that a script could solve that, followed by some manual review.

The original idea was that updating to new versions was easy, it was a
mv operation. The checksums have of course complicated this idea but the
principle still applies. It also lets you see versions without having to
view the files themselves which I know I personally find very useful.

Also, as others have mentioned, git can detect move operations if you
tell it to.

Cheers,

Richard
Bruce Ashfield - July 26, 2012, 7:52 p.m.
On Wed, Jul 25, 2012 at 6:09 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday 25 July 2012 07:23:31 Iorga, Cristian wrote:
>> For me, having the version number contained in the name of package recipe is
>> a little bit puzzling. For example: libpcre/libpcre_8.31.bb
>>
>> Is there a solid technical reason to not have it like this?
>>
>> libpcre/libpcre.bb
>> and inside the recipe to have a PV variable defined:
>> PV="8.31"
>
> The benefit of having PV in the recipe file name is that you can then easily
> have different recipes for different versions of the same piece of software,
> which is particularly useful when those different versions may need to be built
> slightly differently.

And an example would be the three linux-yocto kernel versions. We'd have
to break them out into separate layers if the version wasn't in the filename.

That being said, the linux-yocto-dev recipe doesn't have a version in it's name
for the same reason, it's simpler to keep it moving forward constantly without
the version in the name.

.. just chiming in from the kernel point of view :)

Cheers,

Bruce

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Joshua Lock - July 26, 2012, 8:44 p.m.
On Thu, 2012-07-26 at 20:40 +0100, Richard Purdie wrote:
> On Wed, 2012-07-25 at 07:23 +0000, Iorga, Cristian wrote:
> > For me, having the version number contained in the name of package recipe is a little bit puzzling.
> > For example: libpcre/libpcre_8.31.bb
> > 
> > Is there a solid technical reason to not have it like this?
> > 
> > libpcre/libpcre.bb
> > and inside the recipe to have a PV variable defined:
> > PV="8.31"
> 
> FWIW, you can do that and it will just work, even today. Its just not
> the convention we've "grown up" with.
> 
> > In that case, the upgrade/update process would not involve performing a "git move" operation.
> > In my opinion, this "git move" operation is something to be avoided, as it puzzles a little bit the versioning system and complicates the review process.
> > 
> > Of course, some changes in the bitbake system would be involved, but I guess would not be too complicated.
> > Also, there will be a volume of work to be performed for changing the name of recipes and adding the PV variable inside the recipe.
> > But I guess that a script could solve that, followed by some manual review.
> 
> The original idea was that updating to new versions was easy, it was a
> mv operation. The checksums have of course complicated this idea but the
> principle still applies. It also lets you see versions without having to
> view the files themselves which I know I personally find very useful.
> 
> Also, as others have mentioned, git can detect move operations if you
> tell it to.

FYI the create-pull-request script passes -M40 to git format-patch,
which tells git to:

"should consider a delete/add pair to be a rename if more than 40% of
the file hasn’t changed."

Though with the size of some recipes perhaps the -M value should be
increased, or not passed at all?

Joshua
Anders Darander - July 28, 2012, 9:22 a.m.
On 26 jul 2012, at 22:43, "Joshua Lock" <josh@linux.intel.com> wrote:
> On Thu, 2012-07-26 at 20:40 +0100, Richard Purdie wrote:

>> 

>> Also, as others have mentioned, git can detect move operations if you

>> tell it to.

> 

> FYI the create-pull-request script passes -M40 to git format-patch,

> which tells git to:

> 

> "should consider a delete/add pair to be a rename if more than 40% of

> the file hasn’t changed."

> 

> Though with the size of some recipes perhaps the -M value should be

> increased, or not passed at all?


No, the -M option shouldn't be removed. Why would you like to increase the percentage needed to handle a delete/add pair as a rename? Rather, it could very well be lowered even more, though the current 40% might be a good compromise.

Detecting a delete/add pair as a rename operation with some further modifications of the recipe does make reviewing the upgrade patches a lot easier...

Cheers,
Anders
Darren Hart - Aug. 3, 2012, 11:46 p.m.
On 07/28/2012 02:22 AM, Anders Darander wrote:
> 
> On 26 jul 2012, at 22:43, "Joshua Lock" <josh@linux.intel.com>
> wrote:
>> On Thu, 2012-07-26 at 20:40 +0100, Richard Purdie wrote:
>>> 
>>> Also, as others have mentioned, git can detect move operations if
>>> you tell it to.
>> 
>> FYI the create-pull-request script passes -M40 to git
>> format-patch, which tells git to:
>> 
>> "should consider a delete/add pair to be a rename if more than 40%
>> of the file hasn’t changed."
>> 
>> Though with the size of some recipes perhaps the -M value should
>> be increased, or not passed at all?
> 
> No, the -M option shouldn't be removed. Why would you like to
> increase the percentage needed to handle a delete/add pair as a
> rename? Rather, it could very well be lowered even more, though the
> current 40% might be a good compromise.
> 
> Detecting a delete/add pair as a rename operation with some further
> modifications of the recipe does make reviewing the upgrade patches a
> lot easier...

Right, Anders submitted the -M40 change deliberately:

This was introduced as:

commit c8294d1e6da20f82d444a9d866bf5444a002dc5c
Author: Anders Darander <anders@chargestorm.se>
Date:   Tue Aug 16 15:41:34 2011 +0200

    create-pull-request: increase likelihood of detecting a rename

    Decrease the similarity percentage needed to recognize a
delete/add-pair follow
    as a rename.
    This make reviewing patches easier.

    (From OE-Core rev: 3944f5e02d22b70b3bcd733a80f005dbd8e248a2)

    Signed-off-by: Anders Darander <anders@chargestorm.se>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This hasn't been an issue for me, but I could see that with some of the
minimal recipes that this could trigger some false renames. Still, I
don't see it as a problem.