3 ms·
There was another mail sent to ML regarding v1.1.0: https://www.freelists.org/post/metastore-announce/metastore-v110,1 https://www.freelists.org/post/metastore
by przemoc 11y ago
There was another mail sent to ML regarding v1.1.0:
https://www.freelists.org/post/metastore-announce/metastore-v110,1 https://www.freelists.org/post/metastore-announce/metastore-...
- jcr 11y agoThanks for working on this and posting it to hn. The security concerns around storing /etc improperly (i.e. like publicly in a version control system) are well known, but if done right, it could really be useful.
- przemoc 11y agometastore was used in etckeeper in the past. https://joeyh.name/blog/entry/announcing_etckeeper/ https://joeyh.name/blog/entry/announcing_etckeeper/ In less than half a year it was replaced with find scripts. http://git.joeyh.name/?p=etckeeper.git;a=commitdiff;h=a9ce9965c065 http://git.joeyh.name/?p=etckeeper.git;a=commitdiff;h=a9ce99... And I cannot blame etckeeper. Using binary format for storing metadata, i.e. owner, group, perms, xattrs, mtime, makes it too opaque for many use cases, especially in VCS. metastore v1.1.0, as you can already read, was meant to give metastore (from 2008) a proper release, with fixed bugs and small improvements only. There are plans to make metastore more useful in the future, though.