[OE-core] [PATCH] libcomps: put PV in filename

[Martin Jansa]

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 at 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 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190327/576d3ca0/attachment.sig>