getting the running patch level

[olli hauer]

On 2012-08-22 13:40, olli hauer wrote:
> On 2012-08-22 12:44, Adrian Penisoara wrote:
>> Hello,
>>
>> On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis <marquis at roble.com> wrote:
>>> Jilles Tjoelker wrote:
>> [...]
>>>
>>> WRT writing a new file, something like /etc/bsd-release would be a good
>>> choice following the principle of least surprise.  Mergemaster can and
>>> should ignore it (and motd, issue, ...).
>>>
>>
>>   I support the idea of using an /etc/*-release file to tag (and this
>> makes me think about /var/db/freebsd-update/tag) the current release
>> version details of the system (not only the kernel, but the whole
>> installed system). This seems to be a popular choice among Linux
>> distributions and thus ISV's should feel comfortable with the
>> approach.
>>
>>   Mergemaster and/or other updating mechanisms should update the file
>> to reflect the reality after upgrades/updates.
>>
>>   Now the format of the file would be also debatable: other vendors
>> releasing derivative works from the main FreeBSD source tree (like
>> FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should
>> we retain only the vendor's release tag or should we have a multiple
>> entries (for the original FreeBSD version and the vendor) ? Should we
>> even think about multiple ${vendor}-release files or just bsd-release
>> ?
> 
> In case a new file will be used, I suggest using the cpe framework,
> see http://cpe.mitre.org/specification/
> 
> Using a standard framework makes it easier to write platform
> independent tools for example in visualization environments.

s/visualization/virtualization/

> 
> sample /etc/system-release-cpe entry
> cpe:/o:freebsd:8.3:ga:x64 ...