All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
Cc: Michael Nosthoff <buildroot@heine.tech>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [RFC 2/2] docs/manual/migrating.txt: add "individual packages" section
Date: Tue, 3 Aug 2021 07:48:42 +0200	[thread overview]
Message-ID: <20210803054842.GF27036@scaer> (raw)
In-Reply-To: <20210802162244.620782-2-arnout@mind.be>

Arnout, All,

On 2021-08-02 18:22 +0200, Arnout Vandecappelle (Essensium/Mind) spake thusly:
> Add a section to the migrating documentation to explain what changed in
> individual packages and how it may affect your build.
> 
> This section is organised per package, not per Buildroot release,
> because in general it's easier to check package per package if anything
> changed than to check release per release for all your packages.
> 
> The idea is that every time a package is changed in a way that is not
> immediately obvious (mainly: affects runtime but not build time), it is
> mentioned in this section. This may include:
> 
> - a new version of the package got a new name due to API
>   incompatibilities;
> - the default behaviour or config optoins of the package changed;
> - the Buildroot integration (e.g. configuration file, init script) of
>   the package changed;
> - what is installed by the package is changed (e.g. executable is
>   renamed or removed).

No. Please, no.

We already have two locations were changes in packages are identified:

  - git commit logs, the authoritative reference,

  - the CHANGES files

I do not want to have to maintain yet a third, ever-growing and
never-trimmed list. Also, we will always have to bikeshed whther such a
change is disruptive enough or not to warrant being on that list...

Instead, I would just suggest that people run "git log --oneline" or
"git log -p --stat" on the packages they are interested in.

And of course, that means we *need* well-written commit logs (but we're
already pretty good I believe).

Having a section about the core internals, like the br2-defconfig stuff
that is not obvious, or about the RPATH of host packages, is acceptable,
because it is not easily discoverable.

Regards,
Yann E. MORIN.

> To start with, add the recent changes of the installation defaults of
> bluez5_utils.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  docs/manual/migrating.txt | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/manual/migrating.txt b/docs/manual/migrating.txt
> index 9fd7d7e676..36e4aa4724 100644
> --- a/docs/manual/migrating.txt
> +++ b/docs/manual/migrating.txt
> @@ -22,8 +22,8 @@ To migrate from an older Buildroot version, take the following steps.
>    the existing +.config+.
>  . If anything is enabled in the Legacy menu, check its help text,
>    unselect it, and save the configuration.
> -. Review the CHANGES file to see if any of your packages and features
> -  are affected by the changes.
> +. Review the individual packages section below to see if any of your
> +  packages are affected by the changes.
>  . Build in the new Buildroot environment.
>  . Fix build issues in external packages (usually due to updated
>    dependencies).
> @@ -36,6 +36,17 @@ To migrate from an older Buildroot version, take the following steps.
>  . Run +make savedefconfig+ and verify that what is selected really is
>    what you intended to enable.
>  
> +[[migrating-packages]]
> +=== Individual packages
> +
> +This section describes changes to individual packages. For all packages
> +that are built in your configuration, check below if changes are needed.
> +
> +==== bluez5_utils
> +
> +Since 2021.08, the tools and all plugins are optional and default off.
> +Make sure to enable the plugins you require.
> +
>  [[br2-external-converting]]
>  === Migrating to 2016.11
>  
> -- 
> 2.31.1
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

  reply	other threads:[~2021-08-03  5:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 16:22 [Buildroot] [RFC 1/2] docs/manual/migrating.txt: add section with general migrating tips Arnout Vandecappelle (Essensium/Mind)
2021-08-02 16:22 ` [Buildroot] [RFC 2/2] docs/manual/migrating.txt: add "individual packages" section Arnout Vandecappelle (Essensium/Mind)
2021-08-03  5:48   ` Yann E. MORIN [this message]
2021-08-03 15:19     ` Arnout Vandecappelle
2021-08-03 18:56       ` Michael Nosthoff via buildroot
2021-08-03 19:47         ` Yann E. MORIN
2021-08-03 21:35           ` Thomas Petazzoni
2021-08-02 20:55 ` [Buildroot] [RFC 1/2] docs/manual/migrating.txt: add section with general migrating tips Yann E. MORIN
2021-08-03 15:18   ` Arnout Vandecappelle

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=20210803054842.GF27036@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=arnout@mind.be \
    --cc=buildroot@buildroot.org \
    --cc=buildroot@heine.tech \
    --cc=thomas.petazzoni@bootlin.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.