[lsb-discuss] Potential overlap with freedesktop.org?
rjschwei at suse.com
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:
>>> In a discussion about user naming on the openSUSE factory list ,
>>> 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. 
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
> 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 ). 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.
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