> > I don't know of any other implementation that alrerady supports as > > wide a variety of existing platfom xattr's/acl's, is as simple to use > as tar, > and can be extended to handle new per-file metadata rather easily. >
Maybe not directly connected, i am't sure, but could be interesting to look at libferris and see if it can offer any interesting idea for RPM, or for a package management system in general. http://www.linuxjournal.com/article/8901 It was some time which I am thinking about it but i haven't able until now to see for what measure can be useful (perhaps rollback without saving rpm e.g a journal metadata or the like). It could be of starting point for a future evolution of the RPM. * *Best Regards On Sat, Apr 19, 2008 at 4:27 PM, Jeff Johnson <[EMAIL PROTECTED]> wrote: > > On Apr 19, 2008, at 8:13 AM, devzero2000 wrote: > > I personally find much interesting the last discussion, as a general rpm > improvement of course. Maybe at a certain historical moment the battle tar > vs star was due to selinux problems (xtattr and the like). It is obviously > a hypothesis. But maybe these problems that were present are not such any > more or, almost, with minor problem (* > http://www.redhatmagazine.com/2007/07/02/tips-from-an-rhce-tar-vs-star-the-battle-of-xattrs/ > ) > * > Ma perhaps this are patch not upstream: to do verified. > > But the discussion could deviate again..................* > > *Best Regards > > > Part of the reason for preferring star over tar around a RHEL4 time > frame was the ability to save xattr's (and other information like ACL's), > yes. > > The major reason for avoiding star has to do with the maintainer and > politics. The star code itself has always been high performing, > innovative, well maintained, etc. And extremely well marketed > to put it mildly. > > I personally think that tar as a format is rather terrible and > inefficient. > Blocking to 512b buffers for all reads is extremely useful for designing > hardware buffers for DMA transfers to serial tape drives and is otherwise > largely pointless. The main advantage of tar over its hysterical rival > cpio > is ease of use. I still have to read cpio(1) to figger out how to use, 20 > years later. > But perhaps that's a fault of mine, not cpio implementations. > > And there's ar(1), but I'll leave the advantages of that bizzare format to > dpkg fan-boys > and static library devotee's. Wotta mess is my personal opinion. > > I point you at XAR if interested in backups of additional data like > xattr's and ACL's > and plists. I don't know of any other implementation that alrerady > supports as > wide a variety of existing platfom xattr's/acl's, is as simple to use as > tar, > and can be extended to handle new per-file metadata rather easily. > > XAR does have the advantage of not being mired with hysterical "standard" > legacy baggage. If "standard" compliance is of interest, XAR is not for > you. > > Which is largely why I like XAR not only for its payload handling, but > also > for the ability to represent package metadata. > > 73 de Jeff >
