On Tue, 2020-09-22 at 11:06 -0500, Seebs wrote: > On Tue, 22 Sep 2020 14:18:24 +0100 > "Richard Purdie" <[email protected]> wrote: > > > This can happen when files are deleted outside of pseudo context and > > the inode is reused by a new file which pseduo then "sees". > > In terms of the original design: This would be considered a usage bug, > and pseudo issues diagnostics for that. Once files are owned by an > instance of pseudo, it expects to "see" every change to those files, > and if you don't do that, then yes, the database is corrupt. But in > some cases, the behavior was something like "a move within a pseudo > filesystem" or something similar, and losing the data would also be > bad. > > Basically, the original design philosophy is that you should *never* > be modifying things pseudo owns outside of pseudo. And that does impose > a performance cost on things, *but*, it also gives us a lot of > confidence in results.
The "fun" here is that "make install" is rewriting Makefiles within the source code tree. The install step runs under pseudo, earlier ones do not. If we rerun earlier non-pseudo steps, the Makefiles get reset to their original state, then "make install" modifies them again. We don't run unpack/configure/compile under pseudo for performance reasons, these steps don't do anything we care about from a pseudo perspective. > So my preference on "deleting files outside of pseudo context, inode > gets reused" would be "don't do that then"; this is why pseudo reports > diagnostics for those. Being able to tell you what the old path was > in such cases was actually one of the primary reasons pseudo exists. We're not intentionally doing it. Perl's makefiles are doing crazy things. I'm not sure we can: a) afford to run everything under pseudo or b) catch every case of code which modifies files in unexpected places Part of the trouble here is that we can't tell pseudo "only monitor files <here>". Realistically, it can't expect to monitor every file on the system either. We are breaking pseudo's original design, but in general it seems to work out fine (and we've been doing pretty this for many years now). We may need to accept we're not operating entirely as designed and consider if we could/should be changing some of the responses to these corner cases accordingly as I don't think we can realistically avoid them? Not sure where this leaves us :( Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142726): https://lists.openembedded.org/g/openembedded-core/message/142726 Mute This Topic: https://lists.openembedded.org/mt/77012533/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
