Date: Sun, 29 Nov 2015 11:04:26 -0700 From: Warner Losh <imp@bsdimp.com> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: mtree "language" enhancements Message-ID: <CANCZdfrDtfkwKxMV3o9tcQNzBQDKZdTx1JErkTKtC7UZORT5aA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Greetings, As part of making NanoBSD buildable by non-root, I've found a need to have a richer mtree language than we currently have. mtree started out as a language to express hierarchies of files. It does a decent job at that, even if some of the tools that we have in the tree aren't so great about manipulating them. One could easily wish for better tools, but that's not the topic of this thread. So, I've started to move the language into one that can also journal changes to a tree, and have been moving NanoBSD to using wrappers that do the changes to the tree and record the journal events at the end of the metalog produced from buildworld. I have a second tool that reads the meta log, and applies the actions to the earlier entries and then produces a final metalog that's used for makefs. These tools are still evolving, but before I got too close to the point of committing, I thought I'd post a proposed extension to mtree for comments so I don't have to change too much. I'd like a new type called 'action' (so type=action in the records). This type is defined loosely to manipulate and earlier entry (or maybe entries, still unsure) in the file. Each action entry would have an 'action' keyword. The keywords I've defined so far are as follows: 1. "unlink" which throws away the previous entry. That entry has been removed. It may apply to files or directories, but it is an error not to remove all entries in a directory when removing the directory. 2. "move" which relocates a previous entry. An additional targetpath keyword specifies the ultimate destination for this entry. 3. "copy" which duplicates a previous entry. It too takes targetpath. 4. "meta" which changes the meta data of the previous entry. All keywords on this are merged with the previous entry. The one other thing that my merging tool does is to remove all size keywords. In the NanoBSD environment, size is irrelevant. Files are replaced and appended to all the time in the build process, and it doesn't make sense to track the size. makefs fails if the size is different, so post-processing of the tree, say to add a new default to /etc/defaults/rc.conf or to tweak /etc/ttys to turn on/off a tty (or append a new entry) will cause it to fail. I would be nice of mtree could do this, but is simply can't (but see above for whining about better tools being beyond the scope of this). If things go well, we could eventually move these extensions into mtree so that the post-processing stage is no longer necessary. I'm content to maintain the hundred or two lines of awk I've written to implement it. I chose awk because it does the job well enough, though python might do it better. But I don't want to talk about that choice since right now it is purely internal to NanoBSD (though I hope that other build orchestration systems like src/release and crochet look to adopt). Comments? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrDtfkwKxMV3o9tcQNzBQDKZdTx1JErkTKtC7UZORT5aA>