From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yann E. MORIN Date: Fri, 25 Jun 2021 11:32:52 +0200 Subject: [Buildroot] [PATCH 12/15] package/pkg-generic.mk: Generate final rsync exclude file list In-Reply-To: <20210625110530.13089037@fedora> References: <20210621141130.48654-1-herve.codina@bootlin.com> <20210621141130.48654-13-herve.codina@bootlin.com> <20210622211510.GP44262@scaer> <20210625110530.13089037@fedora> Message-ID: <20210625093252.GK2852@scaer> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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" 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 -{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 -{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. | '------------------------------^-------^------------------^--------------------'