All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli via buildroot <buildroot@buildroot.org>
To: yann.morin@orange.com
Cc: <buildroot@buildroot.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [Buildroot] [PATCH] package/pkg-generic: store reall version in legal manifest
Date: Tue, 21 Jan 2025 19:10:44 +0100	[thread overview]
Message-ID: <20250121191044.36864ead@booty> (raw)
In-Reply-To: <Z4/IZbYmCGQLMG4m@yd-6wlzhs3>

Hi Yann,

On Tue, 21 Jan 2025 17:16:37 +0100
yann.morin@orange.com wrote:

> Luca, Al,
> 
> On 2025-01-21 16:55 +0100, Luca Ceresoli spake thusly:
> > On Tue, 21 Jan 2025 11:45:32 +0100
> > <yann.morin@orange.com> wrote:  
> [--SNIP--]
> > > Change the legal manifest to include the actual, original value as
> > > was set in the .mk file.  
>  [--SNIP--]
> > Subject line: reall -> real.  
> 
> :-)
> 
> > It would be nice to shot an actual example in the commit message. I did
> > a very quick search and couldn't find any package where the problem
> > happens.  
> 
> There is no package in the Buildroot tree that is affected, when the
> version string is a constant. There are a few packages (linux, uboot...)
> where the user can specify a custom version from a custom git tree, and
> those could contain a colon or a slash, even a space (but let's be
> honest, that space would break so many other things everywhere!).
> 
> Also, packages from br2-external trees may have versions with any such
> character. For example, I'm looking at Apache ant, where the tags are
> something like "rel/1.10.15" for example:
>     https://github.com/apache/ant/tags
> 
> Finally, private packages (used from a br2-external tree) may have such
> tags as well..

Sure, make sense. If it were me, I'd add an example with one of those
packages for which one can specify the version in a configuration
setting, like U-Boot or Linux, in case you send a v2.

> [--SNIP--]
> > > -	@$$(call legal-manifest,$$(call UPPERCASE,$(4)),$$($(2)_RAWNAME),$$($(2)_VERSION),$$(subst $$(space)$$(comma),$$(comma),$$($(2)_LICENSE)),$$($(2)_MANIFEST_LICENSE_FILES),$$($(2)_ACTUAL_SOURCE_TARBALL),$$($(2)_ACTUAL_SOURCE_SITE),$$(call legal-deps,$(1)))
> > > +	@$$(call legal-manifest,$$(call UPPERCASE,$(4)),$$($(2)_RAWNAME),$$($(2)_DL_VERSION),$$(subst $$(space)$$(comma),$$(comma),$$($(2)_LICENSE)),$$($(2)_MANIFEST_LICENSE_FILES),$$($(2)_ACTUAL_SOURCE_TARBALL),$$($(2)_ACTUAL_SOURCE_SITE),$$(call legal-deps,$(1)))
> > >  endif # ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
> > >  	$$(foreach hook,$$($(2)_POST_LEGAL_INFO_HOOKS),$$(call $$(hook))$$(sep))  
> > Not strictly specific about your patch, but IMO reusing the _DL_VERSION
> > variable makes code less readable. The _DL_VERSION name suggests it is
> > for downloading, right? What about renaming it to e.g. _ORIG_VERSION,
> > and then using _ORIG_VERSION for both the download, the legal manifest,
> > pkg-stats and whatever use is currently made of _DL_VERSION?  
> 
> Vast subject. I'm not going to revisit that; my non-work alter-ego
> previously tried, and that was not easy *at all*; talk to the people
> who were in Vienna if you want a bit of details (one point is that
> some packages may already make use of _DL_VERSION, especially in
> br2-external trees, so we want to keep that as well, but I can't
> remember the key problem I stumbled uppon, just that I went "Ouch,
> burnt! No touching!").

I hereby forget about having suggest such an improvement. O:-)

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2025-01-21 18:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-21 10:45 [Buildroot] [PATCH] package/pkg-generic: store reall version in legal manifest yann.morin
2025-01-21 15:55 ` Luca Ceresoli via buildroot
2025-01-21 16:16   ` yann.morin
2025-01-21 18:10     ` Luca Ceresoli via buildroot [this message]
2025-01-22  6:45       ` yann.morin

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=20250121191044.36864ead@booty \
    --to=buildroot@buildroot.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin@orange.com \
    /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.