| 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/masterComments
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
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
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
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.
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!
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.
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
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
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
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
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.
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(-)