[Toybox] New email, [PATCH] fdisk cleanup, etc.

[Isaac]

On Sun, Aug 11, 2013 at 10:07:49PM -0500, Rob Landley wrote:
> On 08/11/2013 07:42:37 PM, Isaac wrote:
> >I also have some code here that *should* handle writing a member
> >of a cpio
> >newc archive, loopfiles_stdin(), and a general idea of how to proceed.
> >Don't expect much soon.
> >(newc is essentially an octal dump of struct stat; oldc differs
> >only in
> >having a few fields missing or differently sized. cpio is
> >well-suited to
> >loopfiles, except it reads from stdin.
> 
> I've only been looking at newc, because that's what initramfs uses.
> If RPM (the other major modern user of cpio I'm aware of) also uses
> newc, then that's probably all we need to implement. (Dunno about
> full rpm support, but we should be able to do rpm2cpio.)

http://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt
https://github.com/ereshetova/rpm/blob/master/lib/cpio.h

Yes, that's what RPM uses. 
mksh used to be distributed in cpio odc format, which really doesn't
take all that different code. They use some tar format now.

By the way: for extracting CPIO archives, if nlink > 1, check devmajor, 
devminor, and ino. If they have not been recorded, record and extract; 
if they have, create a hard link.
I'm guessing you'd need something vaguely like this:
struct list_members{
struct list_members *next;
struct list_members *prev;
int orig_ino; //24 bits saved
int nlink; // decrement by 1 on every write matching file?
dev_t orig_dev; //devmajor + devminor on newc/"SVR4"
long new_ino;
dev_t new_dev;
}


> There was a really fun trick somebody suggested last decade in
> busybox, which was to grab the metadata header part of each rpm file
> you install and dump it in a directory, then just do the rpm -qpi
> code to read what's installed. (So no database, just a directory of
> chunks of the files.)

I remember seeing that discussion.
By the way, this reminds me of Mastodon Linux ("as free of GNUware as 
is practical with Linux"), xpkg, and makepkg.
http://www.mastodon.biz/
http://www.pell.portland.or.us/~orc/Code/
http://www.pell.portland.or.us/~orc/Code/xrpm/
^This is where xpkg/makepkg come from. They can create or extract RPM
packages, or at least some version thereof.
(Coincidentally, he ended up writing a mail forwarder because that was
simpler than getting configure to run on one platform he was using.)

> The main reason we never bothered was all the install script
> nonsense that can do arbitrary turing complete stuff at install and
> uninstall time. I just basically never got around to it...
> 
> >I'm working on cpio instead of pax because (a) I want to write an
> >initrd,
> >and (b) pax has a much more complex specification).
> 
> I was only planning on doing tar, not pax. I'm aware Solaris got it
> into posix, but I don't care. Almost nobody uses it on Linux,
> everybody uses tar instead.

/me raises hand sheepishly

I use it on occasion; mainly because it's MirBSD pax vs. GNU cpio 
and GNU tar.  pax supports all the formats (except the oddball ancient 
Solaris and V7 tarballs?), is smaller than either, and doesn't have 
builtin support for reading and writing files and tapes on remote servers 
(seriously: what else do you expect of *GNU* cpio and tar?)
And it's got a meaningful manpage.

On the other hand, I tremble at the thought of GNU deciding to implement 
pax.

Thanks,
Isaac Dunham

 1376285405.0