| Message ID | 20190325234413.12652-1-ross.burton@intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | libcomps: put PV in filename | expand |
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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" > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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" >> > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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"
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%) -- 2.11.0 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core