[PATCH] libcomps: put PV in filename

[PATCH] libcomps: put PV in filename

[Ross Burton]

This isn't a git snapshot recipe but a release that is fetched over it.  For
clarity, put the PV in the filename.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} | 1 -
 1 file changed, 1 deletion(-)
 rename meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} (98%)

diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
similarity index 98%
rename from meta/recipes-devtools/libcomps/libcomps_git.bb
rename to meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
index ff6820851fe..1c4f3bde65e 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
@@ -9,7 +9,6 @@ SRC_URI = "git://github.com/rpm-software-management/libcomps.git \
            file://0001-Add-crc32.c-to-sources-list.patch \
            "
 
-PV = "0.1.10"
 SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
 
 S = "${WORKDIR}/git"
-- 
2.11.0

Re: [PATCH] libcomps: put PV in filename

[Khem Raj]

On Mon, Mar 25, 2019 at 4:44 PM Ross Burton <ross.burton@intel.com> wrote:
>
> This isn't a git snapshot recipe but a release that is fetched over it.  For
> clarity, put the PV in the filename.

I think its better to keep it as it is. since its easy to trace git log history.

>
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} | 1 -
>  1 file changed, 1 deletion(-)
>  rename meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} (98%)
>
> diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> similarity index 98%
> rename from meta/recipes-devtools/libcomps/libcomps_git.bb
> rename to meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> index ff6820851fe..1c4f3bde65e 100644
> --- a/meta/recipes-devtools/libcomps/libcomps_git.bb
> +++ b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> @@ -9,7 +9,6 @@ SRC_URI = "git://github.com/rpm-software-management/libcomps.git \
>             file://0001-Add-crc32.c-to-sources-list.patch \
>             "
>
> -PV = "0.1.10"
>  SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
>
>  S = "${WORKDIR}/git"
> --
> 2.11.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] libcomps: put PV in filename

[Burton, Ross]

On Tue, 26 Mar 2019 at 01:39, Khem Raj <raj.khem@gmail.com> wrote:
> > This isn't a git snapshot recipe but a release that is fetched over it.  For
> > clarity, put the PV in the filename.
>
> I think its better to keep it as it is. since its easy to trace git log history.

So should I be renaming gcc-8.3.bb to gcc_http.bb?  If the argument is
that the filename should contain the transport protocol and PV is
embedded in the recipe so that git log is easier, we should be
applying that rule consistently.

Ross

Re: [PATCH] libcomps: put PV in filename

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

On Tue, Mar 26, 2019 at 10:00:52AM +0000, Burton, Ross wrote:
> On Tue, 26 Mar 2019 at 01:39, Khem Raj <raj.khem@gmail.com> wrote:
> > > This isn't a git snapshot recipe but a release that is fetched over it.  For
> > > clarity, put the PV in the filename.
> >
> > I think its better to keep it as it is. since its easy to trace git log history.
> 
> So should I be renaming gcc-8.3.bb to gcc_http.bb?  If the argument is
> that the filename should contain the transport protocol and PV is
> embedded in the recipe so that git log is easier, we should be
> applying that rule consistently.

FWIW: I agree with Khem.

http fetcher won't (usually) fetch different version just by changing 1
variable inside the recipe and vice versa, renaming the recipe won't
fetch different SRCREV with git.

If someone wants to update SRCREV in libcoms to be 10 commits behind
0.1.10, is he expected to rename the recipe back to libcomps_git.bb and
re-add the PV variable (with new +git${SRCPV} suffix)?

I got used to "+git${SRCPV}" being dropped when the SRCREV matches
exactly the git tag, but renaming the recipe and removing the PV seems
too much, what is the benefit of doing that? It's not for clarity or
easier maintenance (at least for me), because PV next to SRCREV makes
much more sense to me (and helps people not to forget updating both at
the same time).

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [PATCH] libcomps: put PV in filename

[Burton, Ross]

On Tue, 26 Mar 2019 at 10:20, Martin Jansa <martin.jansa@gmail.com> wrote:
> http fetcher won't (usually) fetch different version just by changing 1
> variable inside the recipe and vice versa, renaming the recipe won't
> fetch different SRCREV with git.

Sure it will.  gcc_http.bb sets PV=8.3.0 in the recipe, and SRC_URI
uses ${PV}.  The only catch is that http fetches have a secondary
layer of transport checksums that git doesn't have.

> If someone wants to update SRCREV in libcoms to be 10 commits behind
> 0.1.10, is he expected to rename the recipe back to libcomps_git.bb and
> re-add the PV variable (with new +git${SRCPV} suffix)?

Yes.  The recipe ships a release.  If the recipe is changed from
shipping a tested and maintainer approved release to a git snapshot,
that definitely should not be trivial.

> I got used to "+git${SRCPV}" being dropped when the SRCREV matches
> exactly the git tag, but renaming the recipe and removing the PV seems
> too much, what is the benefit of doing that? It's not for clarity or
> easier maintenance (at least for me), because PV next to SRCREV makes
> much more sense to me (and helps people not to forget updating both at
> the same time).

For clarity and consistency: by convention recipes that ship releases
put the PV in the filename.

Ross

Re: [PATCH] libcomps: put PV in filename

[Adrian Bunk]

On Tue, Mar 26, 2019 at 11:20:17AM +0100, Martin Jansa wrote:
> On Tue, Mar 26, 2019 at 10:00:52AM +0000, Burton, Ross wrote:
> > On Tue, 26 Mar 2019 at 01:39, Khem Raj <raj.khem@gmail.com> wrote:
> > > > This isn't a git snapshot recipe but a release that is fetched over it.  For
> > > > clarity, put the PV in the filename.
> > >
> > > I think its better to keep it as it is. since its easy to trace git log history.
> > 
> > So should I be renaming gcc-8.3.bb to gcc_http.bb?  If the argument is
> > that the filename should contain the transport protocol and PV is
> > embedded in the recipe so that git log is easier, we should be
> > applying that rule consistently.
> 
> FWIW: I agree with Khem.
> 
> http fetcher won't (usually) fetch different version just by changing 1
> variable inside the recipe and vice versa, renaming the recipe won't
> fetch different SRCREV with git.

Why should the name of the recipe depend on whatever fetcher is 
currently used?

If the same gcc release would be fetched from the upstream SVN,
would you argue that the recipe has to be renamed to gcc_svn.bb?

> If someone wants to update SRCREV in libcoms to be 10 commits behind
> 0.1.10, is he expected to rename the recipe back to libcomps_git.bb and
> re-add the PV variable (with new +git${SRCPV} suffix)?
> 
> I got used to "+git${SRCPV}" being dropped when the SRCREV matches
> exactly the git tag, but renaming the recipe and removing the PV seems
> too much, what is the benefit of doing that?

Is it actually a benefit to make it easy to switch from a release to 
some random git snapshot?

This is not something that should happen frequently.

> It's not for clarity or
> easier maintenance (at least for me), because PV next to SRCREV makes
> much more sense to me (and helps people not to forget updating both at
> the same time).

There are not only developers, but also users.

It is valuable to see from the filename whether it is a release
(and which release it is) or some VCS snapshot.

Not having the release there also loses the ability to use either
gcc_%.bbappend or gcc_8.3.0.bbappend, which are suitable for
different situations.

> Regards,

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] libcomps: put PV in filename

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

On Tue, Mar 26, 2019 at 10:32:07AM +0000, Burton, Ross wrote:
> On Tue, 26 Mar 2019 at 10:20, Martin Jansa <martin.jansa@gmail.com> wrote:
> > http fetcher won't (usually) fetch different version just by changing 1
> > variable inside the recipe and vice versa, renaming the recipe won't
> > fetch different SRCREV with git.
> 
> Sure it will.  gcc_http.bb sets PV=8.3.0 in the recipe, and SRC_URI
> uses ${PV}.  The only catch is that http fetches have a secondary
> layer of transport checksums that git doesn't have.

I'm sorry, that's not what I meant.

git fetcher fetches whatever SRCREV is defined in the recipe, no matter
what PV says, I've seen enough recipe upgrades which just renamed the
recipe to have new version in filename updating SRCREV and even claimed
that the upgrade was properly tested, because nothing got broken :).

In webOS we got a bit further and PV+SRCREV are defined in one variable
WEBOS_VERSION and do_fetch qa check tests that the SRCREV points to
matching annotated version tag in the component.

> > If someone wants to update SRCREV in libcoms to be 10 commits behind
> > 0.1.10, is he expected to rename the recipe back to libcomps_git.bb and
> > re-add the PV variable (with new +git${SRCPV} suffix)?
> 
> Yes.  The recipe ships a release.  If the recipe is changed from
> shipping a tested and maintainer approved release to a git snapshot,
> that definitely should not be trivial.

Next time someone needs to include few bugfixes from stable branch
included just after the release, should he update the SRCREV or add them
as .patch files?

> > I got used to "+git${SRCPV}" being dropped when the SRCREV matches
> > exactly the git tag, but renaming the recipe and removing the PV seems
> > too much, what is the benefit of doing that? It's not for clarity or
> > easier maintenance (at least for me), because PV next to SRCREV makes
> > much more sense to me (and helps people not to forget updating both at
> > the same time).
> 
> For clarity and consistency: by convention recipes that ship releases
> put the PV in the filename.

FWIW: in webOS we don't use any version in filename, most recipes are
called just PN.bb and it works fine as well for us, less renames and
version consistently defined inside the recipes.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [PATCH] libcomps: put PV in filename

[Burton, Ross]

On Tue, 26 Mar 2019 at 11:02, Martin Jansa <martin.jansa@gmail.com> wrote:
> git fetcher fetches whatever SRCREV is defined in the recipe, no matter
> what PV says, I've seen enough recipe upgrades which just renamed the
> recipe to have new version in filename updating SRCREV and even claimed
> that the upgrade was properly tested, because nothing got broken :).
>
> In webOS we got a bit further and PV+SRCREV are defined in one variable
> WEBOS_VERSION and do_fetch qa check tests that the SRCREV points to
> matching annotated version tag in the component.

Agreed that is a genuine problem and is definitely something patchtest
should be catching these days.

> Next time someone needs to include few bugfixes from stable branch
> included just after the release, should he update the SRCREV or add them
> as .patch files?

Patches ideally, as we can pick them without other unintended changes.

> FWIW: in webOS we don't use any version in filename, most recipes are
> called just PN.bb and it works fine as well for us, less renames and
> version consistently defined inside the recipes.

That makes complete sense, PV in filename is pretty much legacy from
the old days, along with recipes split into a bb/inc where there's
only one recipe.

Ross

Re: [PATCH] libcomps: put PV in filename

[Khem Raj]

On Tue, Mar 26, 2019 at 3:01 AM Burton, Ross <ross.burton@intel.com> wrote:
>
> On Tue, 26 Mar 2019 at 01:39, Khem Raj <raj.khem@gmail.com> wrote:
> > > This isn't a git snapshot recipe but a release that is fetched over it.  For
> > > clarity, put the PV in the filename.
> >
> > I think its better to keep it as it is. since its easy to trace git log history.
>
> So should I be renaming gcc-8.3.bb to gcc_http.bb?  If the argument is
> that the filename should contain the transport protocol and PV is
> embedded in the recipe so that git log is easier, we should be
> applying that rule consistently.

I would agree on ( foo.bb) for that as well if we do not maintain
several copies of recipes and fetch from SCMs directly, which is more
and more the case these days

>
> Ross

Re: [PATCH] libcomps: put PV in filename

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3555 bytes --]

On Tue, Mar 26, 2019 at 12:42:12PM +0200, Adrian Bunk wrote:
> On Tue, Mar 26, 2019 at 11:20:17AM +0100, Martin Jansa wrote:
> > On Tue, Mar 26, 2019 at 10:00:52AM +0000, Burton, Ross wrote:
> > > On Tue, 26 Mar 2019 at 01:39, Khem Raj <raj.khem@gmail.com> wrote:
> > > > > This isn't a git snapshot recipe but a release that is fetched over it.  For
> > > > > clarity, put the PV in the filename.
> > > >
> > > > I think its better to keep it as it is. since its easy to trace git log history.
> > > 
> > > So should I be renaming gcc-8.3.bb to gcc_http.bb?  If the argument is
> > > that the filename should contain the transport protocol and PV is
> > > embedded in the recipe so that git log is easier, we should be
> > > applying that rule consistently.
> > 
> > FWIW: I agree with Khem.
> > 
> > http fetcher won't (usually) fetch different version just by changing 1
> > variable inside the recipe and vice versa, renaming the recipe won't
> > fetch different SRCREV with git.
> 
> Why should the name of the recipe depend on whatever fetcher is 
> currently used?
> 
> If the same gcc release would be fetched from the upstream SVN,
> would you argue that the recipe has to be renamed to gcc_svn.bb?

It's quite common use case to override SRCREV outside the recipe (at
least during the development) to newer SRCREV or even AUTOREV.

Using _git or _svn in recipe filename was good indicator that this might
be happening.

With e.g. http fetcher the PV is usually used in SRC_URI, so it's less
likely to be inconsistent between what version the recipe (and enduser
visible packages) say and what is actually downloaded and built.

> > If someone wants to update SRCREV in libcoms to be 10 commits behind
> > 0.1.10, is he expected to rename the recipe back to libcomps_git.bb and
> > re-add the PV variable (with new +git${SRCPV} suffix)?
> > 
> > I got used to "+git${SRCPV}" being dropped when the SRCREV matches
> > exactly the git tag, but renaming the recipe and removing the PV seems
> > too much, what is the benefit of doing that?
> 
> Is it actually a benefit to make it easy to switch from a release to 
> some random git snapshot?
> 
> This is not something that should happen frequently.

It's not about easy switching, it's about making sure that SRCREV is
updated at the same time as PV. Which is easier to notice when the 2
variables are set next to each other, than when PV is taken from the
recipe filename and SRCREV (which is the only one which matters when
downloading the source) is set inside the renamed recipe file.

> > It's not for clarity or
> > easier maintenance (at least for me), because PV next to SRCREV makes
> > much more sense to me (and helps people not to forget updating both at
> > the same time).
> 
> There are not only developers, but also users.
> 
> It is valuable to see from the filename whether it is a release
> (and which release it is) or some VCS snapshot.

That's why bitbake shows not only the filename (which isn't really
important for users) but also the PV set in the recipe (either through
the recipe filename or through PV variable set inside the recipe).

> Not having the release there also loses the ability to use either
> gcc_%.bbappend or gcc_8.3.0.bbappend, which are suitable for
> different situations.

There is usually just one version per recipe and even with _git.bb
suffix you can easily do gcc_7+git.bb and gcc_8+git.bb if you need to.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [PATCH] libcomps: put PV in filename

[Adrian Bunk]

On Wed, Mar 27, 2019 at 02:33:14PM +0100, Martin Jansa wrote:
> On Tue, Mar 26, 2019 at 12:42:12PM +0200, Adrian Bunk wrote:
>...
> > Not having the release there also loses the ability to use either
> > gcc_%.bbappend or gcc_8.3.0.bbappend, which are suitable for
> > different situations.
> 
> There is usually just one version per recipe and even with _git.bb
> suffix you can easily do gcc_7+git.bb and gcc_8+git.bb if you need to.

Thud contains 8.2 today, but might have 8.3 tomorrow.

A layer might want to append only to one of them,
or have different appends for different versions.

That's trivial with gcc_8.2.bb and gcc_8.3.bb,
and harder with gcc_8+svn.bb.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] libcomps: put PV in filename

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Wed, Mar 27, 2019 at 04:03:27PM +0200, Adrian Bunk wrote:
> On Wed, Mar 27, 2019 at 02:33:14PM +0100, Martin Jansa wrote:
> > On Tue, Mar 26, 2019 at 12:42:12PM +0200, Adrian Bunk wrote:
> >...
> > > Not having the release there also loses the ability to use either
> > > gcc_%.bbappend or gcc_8.3.0.bbappend, which are suitable for
> > > different situations.
> > 
> > There is usually just one version per recipe and even with _git.bb
> > suffix you can easily do gcc_7+git.bb and gcc_8+git.bb if you need to.
> 
> Thud contains 8.2 today, but might have 8.3 tomorrow.
> 
> A layer might want to append only to one of them,
> or have different appends for different versions.
> 
> That's trivial with gcc_8.2.bb and gcc_8.3.bb,
> and harder with gcc_8+svn.bb.

If your layer has gcc_8.2.bbappend and the recipe in oe-core gets
renamed from gcc_8.2.bb to gcc_8.3.bb in newer thud revision, then your
bbappend will not apply and bitbake will complain that there is no
recipe for your gcc_8.2.bbappend.

Layer which doesn't even parse correctly with different revisions of
the same thud branch isn't really something we should encourage.

gcc_8%.bbappend with some logic inside (e.g. adding some .patch file
only when PV starts with 8.2) will be compatible with both newer and
older revision of thud.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [PATCH] libcomps: put PV in filename

[Böszörményi Zoltán]

2019. 03. 26. 0:44 keltezéssel, Ross Burton írta:
> This isn't a git snapshot recipe but a release that is fetched over it.  For
> clarity, put the PV in the filename.
> 
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>   meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} | 1 -
>   1 file changed, 1 deletion(-)
>   rename meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} (98%)
> 
> diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> similarity index 98%
> rename from meta/recipes-devtools/libcomps/libcomps_git.bb
> rename to meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> index ff6820851fe..1c4f3bde65e 100644
> --- a/meta/recipes-devtools/libcomps/libcomps_git.bb
> +++ b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> @@ -9,7 +9,6 @@ SRC_URI = "git://github.com/rpm-software-management/libcomps.git \
>              file://0001-Add-crc32.c-to-sources-list.patch \
>              "
>   
> -PV = "0.1.10"

# opkg compare-version git "<=" 0.1.10 ; echo $?
1
# opkg compare-version git "<=" 1:0.1.10 ; echo $?
0

You need to increase PE to be able to upgrade the new recipe
in case you publish this package in a repository.

Best regards,
Zoltán Böszörményi

>   SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
>   
>   S = "${WORKDIR}/git"
> 

Re: [PATCH] libcomps: put PV in filename

[Böszörményi Zoltán]

2019. 03. 29. 19:45 keltezéssel, Böszörményi Zoltán írta:
> 2019. 03. 26. 0:44 keltezéssel, Ross Burton írta:
>> This isn't a git snapshot recipe but a release that is fetched over it.  For
>> clarity, put the PV in the filename.
>>
>> Signed-off-by: Ross Burton <ross.burton@intel.com>
>> ---
>>   meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} | 1 -
>>   1 file changed, 1 deletion(-)
>>   rename meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} (98%)
>>
>> diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb 
>> b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
>> similarity index 98%
>> rename from meta/recipes-devtools/libcomps/libcomps_git.bb
>> rename to meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
>> index ff6820851fe..1c4f3bde65e 100644
>> --- a/meta/recipes-devtools/libcomps/libcomps_git.bb
>> +++ b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
>> @@ -9,7 +9,6 @@ SRC_URI = "git://github.com/rpm-software-management/libcomps.git \
>>              file://0001-Add-crc32.c-to-sources-list.patch \
>>              "
>> -PV = "0.1.10"
> 
> # opkg compare-version git "<=" 0.1.10 ; echo $?
> 1
> # opkg compare-version git "<=" 1:0.1.10 ; echo $?
> 0
> 
> You need to increase PE to be able to upgrade the new recipe
> in case you publish this package in a repository.

Sorry, dumb comment, ignore it. PV was overridden inside the recipe.

> 
> Best regards,
> Zoltán Böszörményi
> 
>>   SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
>>   S = "${WORKDIR}/git"
>>
> 

Re: [PATCH] libcomps: put PV in filename

[Burton, Ross]

On Mon, 4 Mar 2019 at 15:12, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I suspect we have this issue in a few cases and having PV next to the
> SRCREV may prompt people to keep things more in sync?

I'm sure we do, but I spotted this one.  The AUH will do the prompting
so I'm not sure what else needs to be kept in sync.

Ross

Re: [PATCH] libcomps: put PV in filename

[Richard Purdie]

On Mon, 2019-03-04 at 11:58 +0000, Ross Burton wrote:
> This isn't a git snapshot recipe but a release that is fetched over
> it.  For
> clarity, put the PV in the filename.
> 
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/recipes-devtools/libcomps/{libcomps_git.bb =>
> libcomps_0.10.0.bb} | 1 -
>  1 file changed, 1 deletion(-)
>  rename meta/recipes-devtools/libcomps/{libcomps_git.bb =>
> libcomps_0.10.0.bb} (98%)
> 
> diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb
> b/meta/recipes-devtools/libcomps/libcomps_0.10.0.bb
> similarity index 98%
> rename from meta/recipes-devtools/libcomps/libcomps_git.bb
> rename to meta/recipes-devtools/libcomps/libcomps_0.10.0.bb
> index ff6820851fe..1c4f3bde65e 100644
> --- a/meta/recipes-devtools/libcomps/libcomps_git.bb
> +++ b/meta/recipes-devtools/libcomps/libcomps_0.10.0.bb
> @@ -9,7 +9,6 @@ SRC_URI = "git://github.com/rpm-software-
> management/libcomps.git \
>             file://0001-Add-crc32.c-to-sources-list.patch \
>             "
>  
> -PV = "0.1.10"
>  SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"

I suspect we have this issue in a few cases and having PV next to the
SRCREV may prompt people to keep things more in sync?

Cheers,

Richard

[PATCH] libcomps: put PV in filename

[Ross Burton]

This isn't a git snapshot recipe but a release that is fetched over it.  For
clarity, put the PV in the filename.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.10.0.bb} | 1 -
 1 file changed, 1 deletion(-)
 rename meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.10.0.bb} (98%)

diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb b/meta/recipes-devtools/libcomps/libcomps_0.10.0.bb
similarity index 98%
rename from meta/recipes-devtools/libcomps/libcomps_git.bb
rename to meta/recipes-devtools/libcomps/libcomps_0.10.0.bb
index ff6820851fe..1c4f3bde65e 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_0.10.0.bb
@@ -9,7 +9,6 @@ SRC_URI = "git://github.com/rpm-software-management/libcomps.git \
            file://0001-Add-crc32.c-to-sources-list.patch \
            "
 
-PV = "0.1.10"
 SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
 
 S = "${WORKDIR}/git"
-- 
2.11.0