[lsb-discuss] In the "new" world
rjschwei at suse.com
Tue Apr 1 18:13:53 UTC 2014
On 04/01/2014 10:59 AM, R P Herrold wrote:
> On Mon, 31 Mar 2014, Robert Schweikert wrote:
>> I know this is reaching a bit as we have not published the meeting minutes
>> from the f2f last week. I did post a high level summary to the wiki
> I know there is the IRC transcript, and some additional
> minutes by others what might profitably be merged as well. No
> doubt we will discuss such at tomorrow's call (alert to Jeff
> as to an agenda item, for both a Collab meeting debrief, and
> as to possibly adding more formal documentation of the event
>> A second example is distribution identification, i.e.
>> http://www.freedesktop.org/software/systemd/man/os-release.html ,
>> this AFAIK is currently not in the standard but is
>> a.) relatively simple to sum up in a problem statement and a solution plus
>> b.) should not be very controversial
>> On the other hand it is already on freedesktop.org.
> I am unclear as to the last 'it' pronoun ... I think the
> 'standard documentation' part is at freedesktop.org,
Yes, the doc is at freedesktop.org and would remain their. Let me flesh
this out with the example LSB specification, following the new template
in the pull request found here:
At times it is necessary for ISVs or software components to determine
the underlying distribution. ISVs may choose to not install or issue
statements about supported configurations based on the identified
Adopt the freedesktop.org /etc/os-release distribution identification
Solution discussion links:
openSUSE 13.1 and later
SUSE Linux Enterprise 12 and later
Fedora XXX and later
> but a
> test interface is not.
Yup, such with this the os-release file would become part of the LSB and
we'd have a test. The distributions in the document are expected to be
"compliant" and pledge to integrate this test into their test suit.
Whether this hapens directly or via some other testing project is
> We have often seen this with
> 'incorporated' third party 'standards' documentation, with the
> testing tools over at LSB code space
> We have discussed in the IRC channel from time to time, and I
> think I have an open bug to start a formal process of
> 'mirroring' into an archive under LSB maintenance, remote
> standards statements.
The mirroring would no longer apply as we will no longer produce a
"formal" specification as we do today.
> We have been burned a few times, when
> linkrot has caused some holes in our 'upstream' references
With everything in text format it will be easy for us to write a tool
that scans all files in the documents directory and verifies that links
are still valid. If a link is no longer reachable an e-mail is sent to
the lsb list alerting us of the problem.
"no longer reachable" would be 3 times in a row if we run the test
weekly. This should avoid short time transient failures and false
positives. I made up the numbers and am not particularly attached to the
time frame, but something in this direction should work reasonably well.
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Public Cloud Architect
rjschwei at suse.com
rschweik at ca.ibm.com
More information about the lsb-discuss