[Buildroot] [PATCH 12/15] package/pkg-generic.mk: Generate final rsync exclude file list

Yann E. MORIN yann.morin.1998 at free.fr
Fri Jun 25 09:32:52 UTC 2021


Hervé, All,

On 2021-06-25 11:05 +0200, Herve Codina spake thusly:
> On Tue, 22 Jun 2021 23:15:10 +0200
> "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:
> > Ideally, we would in fact redirect the package installation to an emoty
> > directory, so that we can actually find what it installs.
> > 
> > However, as has been discussed in the past, this is fraught with
> > unworkable issues. For example, some paths may be hard-coded at
> > configure time and/or build time, and thus the package would still
> > install in the original stagin we presented it with (for target/, this
> > is not an isue, because target/ is never looked at during configure or
> > build, only at install time). Or a package may try to modify an existing
> > file (bad, but still). Or a file just assumes that tdirectory structure
> > exists (bad, but eh...)
> Modifying existing files is no more allowed -> Overwrites detection.

Exactly. But what I mean is that, for packages that really need to
modify an existing file (e.g. to register themselves against another
package's registry), providing an empty target/ is not viable. Yes, that
will trigger the overwrite-detection, and we will have to find a proper
solution for those. Just, installing in an empty target would not work.

So yes, the list of installed files is still the best solution.

> I can add at the end of commit log :
> --- 8< ---
> Using an empty directory for per-package installation directory would be the
> simplest way to find what a package installs.
> However, as it has been discussed in the past, this is fraught with unworkable
> issues. For example, some paths may be hard-coded at configure time and/or build
> time, and thus the package would still install in the original stagin we presented
> it with (for target/, this is not an isue, because target/ is never looked at
> during configure or build, only at install time). Or a package installation
> process just assumes that the directory structure exists (bad, but eh...).
> --- 8< ---
> 
> Is that ok for you ?

Yes. The registration thing is only just a corner case, so needs not be
in the commit log.

> > > +define pkg_final_rsync_after
> > > +	cd $(1); \
> > > +	LC_ALL=C find . \( -type f -o -type l \) -printf '%T@:%i:%#m:%y:%s,%p\n' \
> > > +		| LC_ALL=C sort > $($(PKG)_DIR)/.files-final-rsync$(2).after
> > > +	LC_ALL=C comm -2 \
> > > +		$($(PKG)_DIR)/.files-final-rsync$(2).before \
> > > +		$($(PKG)_DIR)/.files-final-rsync$(2).after \
> > > +		| sed -r -e 's/^[^,]+,./- /' \
> > > +		> $($(PKG)_DIR)/.files-final-rsync$(2).exclude_rsync
> > > +	rm -f $($(PKG)_DIR)/.files-final-rsync$(2).after  
> > 
> > You forgot to remove .files-final-rsync$(2).before
> 
> I cannot remove it in this patch.
> 
> .files-final-rsync$(2).before is generated by .stamp_configured rule calling
> pkg_final_rsync_before call and if we run 'make && make foo-rebuild' the file
> generated by first make invocation will be no more present for second make
> invocation.

Ah, yes, I see now. Thanks.

> We can remove .files-final-rsync$(2).before only after patch
> "package/pkg-generic.mk: Fix per-package <pkg>-{reconfigure,rebuild,reinstall}"
> Indeed, in this patch, pkg_final_rsync_after is called after the per-package
> host and target dir are recreated from scratch.
> 
> I will remove .files-final-rsync$(2).before in a dedicated patch after
> "package/pkg-generic.mk: Fix per-package <pkg>-{reconfigure,rebuild,reinstall}"
> 
> Is that ok for you ?

Yes, it is. 👍

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'



More information about the buildroot mailing list