All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] libcomps: put PV in filename
Date: Tue, 26 Mar 2019 12:42:12 +0200	[thread overview]
Message-ID: <20190326104212.GB19885@localhost> (raw)
In-Reply-To: <20190326102017.GA1929@jama>

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



  parent reply	other threads:[~2019-03-26 10:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 23:44 [PATCH] libcomps: put PV in filename Ross Burton
2019-03-26  1:39 ` Khem Raj
2019-03-26 10:00   ` Burton, Ross
2019-03-26 10:20     ` Martin Jansa
2019-03-26 10:32       ` Burton, Ross
2019-03-26 11:01         ` Martin Jansa
2019-03-26 11:06           ` Burton, Ross
2019-03-26 10:42       ` Adrian Bunk [this message]
2019-03-27 13:33         ` Martin Jansa
2019-03-27 14:03           ` Adrian Bunk
2019-03-27 14:20             ` Martin Jansa
2019-03-26 18:12     ` Khem Raj
2019-03-29 18:45 ` Böszörményi Zoltán
2019-03-29 18:46   ` Böszörményi Zoltán
  -- strict thread matches above, loose matches on Subject: below --
2019-03-04 11:58 Ross Burton
2019-03-04 15:12 ` Richard Purdie
2019-03-04 16:33   ` Burton, Ross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190326104212.GB19885@localhost \
    --to=bunk@stusta.de \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.