Buildroot Archive on 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox