[lsb-discuss] Potential overlap with freedesktop.org?

Mon Apr 7 20:06:06 UTC 2014

On 04/05/2014 04:28 PM, Greg KH wrote:
> On Wed, Apr 02, 2014 at 06:43:58PM -0600, Mats Wichmann wrote:
>> On 04/02/14 18:21, Robert Schweikert wrote:
>>> Hi,
>>>
>>> In a discussion about user naming on the openSUSE factory list [1][2],
>>> Greg KH pointed out that there may be potential overlap with
>>> freedesktop.org and our chosen direction after LSB 5.0.
>>>
>>> I can see areas where this potential exists, but I am not certain if
>>> there is reason for concern.
>>>
>>>  From my point of view our focus on testing, ISV and potentially admin
>>> issues looks at the world form a different angle. That's not to say that
>>> there will not be areas where close collaboration with freedesktop.org
>>> may be a good thing but I still think there is sufficient distinction.
>>>
>>> Just wanted to share this on this list to expand the circle of awareness.
>>
>> Sure, worth keeping in mind.  It was no problem in the old model: if fdo
>> had forged a nice consensus on something, LSB could include it by
>> reference - and would stay out of the way until that happened.  So no
>> conflict there at all.
>
> But why get the LSB involved in things like this at all?

Well, we think there is still an unmet need, but maybe we are out in 
left field. Repeating bits from our discussion on the openSUSE list, as 
they apply here as well. [1]

Even without a formal standard there are things we discussed at the LSB 
meeting that are not part of fdo, today. Although, I see principally no 
reason that there could not be a merging of efforts. But it is not 
immediately obvious what we would do with the the tests, once they are 
freed from the certification framework, LTP might be a good home, and 
how distributions can claim support for a certain feature that happens 
to be on fdo. For example systemd was on fdo long before distributions 
made the decision to use it, and Debian could just as well have decided 
to not use systemd, obviously the decision was rather close. Thus, fdo 
does not, today, provide an infrastructure where people can find a 
feature and then figure out what distribution actually supports the 
particular implementation. Thus, fdo provides a colection of 
projects/upstream code, but it is not necessarily obvious that a given 
project gets picked up by the distributions just because it is on fdo. 
Once could say fdo is necessary but not sufficient.

With the LSB standard (as in formal standard) approach that was fairly 
obvious, if it's in the LSB and a distro is LSB certified than all the 
features are there. In the new approach to LSB this is not immediately 
obvious. But there are discussions of having some kind of "pledge" 
system, i.e. a way for distros to "register", for lack of a better word, 
the features they implement. This is still valuable information for 
ISVs. This could certainly become an aspect of fdo, I have no problem 
with that.

>  You now are
> saying there should be 2 different groups that people should use to
> create cross-distro specs and resolve issues.

Not necessarily. For many it may not be immediately obvious that fdo 
deals with stuff that is not desktop related, naming is important. There 
are also different levels, I think. For example on issue that recently 
emerged is the username and uid topic (this is where the openSUSE 
discussion comes into play [1]). It is not obvious to me how this would 
fit in with fdo as there is nothing to codify. It's a cross distro 
discussion and then an agreement, but maybe I don't understand enough of 
fdo to see the leap that you have already made.

> How will the two groups interact?

I am not certain there is a clear cut answer.

> How will someone pick which one to use?

Well, the dividing line could be policy vs. code. If you have code that 
should be used by all distros fdo is the place. If it's more of a policy 
discussion and decision use LSB.

> And how will the
> inevitable conflicts between issues codified in different ways by the
> two groups be resolved?

These should not exist. From my perspective at the LSB we have no 
interest in the implementation, only in compatibility across 
distributions to make live easier for ISVs. This has not changed.

>
> Was fdo somehow not working well enough for the LSB?

No, stuff that was developed at fdo is part of the LSB, xdg-utils for 
example. But, fdo does not necessarily go far enough. As stated above, 
just because things show up on fdo that does not imply that distros 
actually implement it. Had Debian decided not to use systemd I doubt 
systemd information would have been removed from fdo.

>  Why get into this
> area at all?

Well we are trying to take a different approach. At the heart of it, LSB 
has always been concerned with cross distribution issues. We've just 
trailed the distributions in the past to be a "documenter of accepted 
standards." This had it's pros and cons. A big plus for ISVs is of 
course that they can count on certain stuff being on every LSB certified 
distro. A negative is that because we picked a packaging format we've 
been accused of playing favors.

There is certainly a ton of stuff we did not discuss at the face 2 face 
and there are many aspects that have to evolve. This conversation should 
certainly continue. Maybe the ultimate answer is, use fdo and add some 
sauce and merge stuff from LSB into fdo and call it a day. I don't know. 
What I do know is that most software developers are still paid by 
companies that do not develop FOSS but that need to run on Linux. 
Traditionally this has been the target audience for LSB and there is no 
intention in changing this. From my point of view fdo does not cover 
this aspect of the "Linux ecosystem."

Last but not least, we know that the kernel is really good at not 
breaking user space and Linus gets a fit every time it happens. 
Interestingly enough the stuff that runs in user space is not even close 
to being anywhere near that kind of compatibility. How often has glibc 
broken a bunch of applications because, well the new implementation was 
"more standards compliant."

I agree there is a potential for more overlap between LSB and fdo with 
the new approach, but there are also areas that fdo does not cover, as 
far as I can tell, that we intent to cover in the LSB.

Later,
Robert

[1] http://lists.opensuse.org/opensuse-factory/2014-04/msg00146.html

-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
Public Cloud Architect
rjschwei at suse.com
rschweik at ca.ibm.com
781-464-8147