Re: bin/52432: /etc/dumpdates format egregious

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 27 Jul 2017 10:07:38 +0300
    From:        Christos Zoulas <christos%zoulas.com@localhost>
    Message-ID:  <DB18CE59-8745-4418-9DB6-8058AFE75A29%zoulas.com@localhost>

  | That sounds like a nice and useful project.

Yes, I think so - what is holding it up at the minute (aside from designing
a new format for dump's data - which I would defer right now, just to avoid
the "use XML", "no use json", "no use plist", "it must be ASN1", just use
plain text... discussions - after all we can iterate that a few times, there
is not that much data to record) is that we need some kind of permanent file
system identification in *every* filesystem dump (and clones, like dump_lfs)
is capable of dumping.   Neither the mount point, nor the device name
(incl the device dev_t) is suitable.   It needs to reside inside the filesystem
so raw copies get the same value.    Some kind of GUID is probably needed,
but it needs to be able to be retro-fitted backwards to the older filesystems
(obviously, without breaking them).

What's needed to make that happen I have not looked into yet.   Once a type
and place to store it is identified (the place need not be the same for
different filesystems) then newfs (and equivs) and perhaps even dump itself,
or a new short-life utility just for the purpose, can supply the value,
for filesystems that dont already have something suitable.

  | I thought that other programs in pkgsrc might consult dumpdates,

If there's anything that uses it for dump W type purposes, we can easily
keep an (essentially useless) /etc/dumpdates for that purpose, and it can
be kept as accurate (or inaccurate if you prefer) as it is now.

If there is anything there (aside from a ported dump(8)) which tries
modifying the format, or even using it to work out what would need to be
dumped, then it deserves breaking (it already is, really.)

kre