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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
