Linux Standard Base pulls a phoenix?

[tyme]

Some of us remember the LSB (Linux Standard Base) when it first was created. It ended up being a good thing for the server market, but it never particularly effected the desktop market. Well, that's about to change it seems. They've created a standard for desktop systems, and a group of distributions have jumped on board - I don't know if Mandrake is one of them, but several others are named in the article. Looks like this could be interesting :)

[iphitus]

*shrug* I cant really see that much benefit that will come out of this. Standardisation is a great thing, but there isnt a whole lot of standardisation going on within this spec. Many of the things mentioned are pretty much standard across most major distros anyway.

 

For those who are interested, the spec is here:

http://refspecs.freestandards.org/lsb.shtml#LSB_3_1_0

 

And the news:

http://news.google.com/news?hl=en&hs=VZp&l...tandards22.html

 

Much more useful things would come out of implementation of the various freedesktop.org standards

 

James

Edited April 22, 2006 by iphitus

[tyme]

could make it easier to make packages that work across different distributions. Then again, you are right that the freedesktop.org standards would probably do more good - but aren't they more design/function where as these are more configuration? I haven't read them completely so I'm not 100% sure on that.

[iphitus]

could make it easier to make packages that work across different distributions. Then again, you are right that the freedesktop.org standards would probably do more good - but aren't they more design/function where as these are more configuration? I haven't read them completely so I'm not 100% sure on that.

 

Now that'd be good if the distros used a central repository of core packages, otherwise, you're better off sticking with your own distro's libs.

 

it could be said that it would make it easier for third party vendors to provide packages for multiple distributions, but in that case, there's still the issue of different package management systems -- although arguably that could be avoided by simply alien'ing - which would work fine if the distros all complied.

 

James

[arctic]

LSB pulls a phoenix? Was it dead? If yes, I haven't noticed it.

[tyme]

Well...it wasn't dead so much as very, very quiet.

[Gowator]

It would be good for it to be implemented but the problem seems to be too many camps.

On one hand you have the Suse people who have a highly modified system with all sorts of links into YaST and at the other end the LFS or arch's who have their /etc

 

... but all of this is IMHO missing the point.

 

The real standardisation needs to come from real developers not distro hackers and the distro hackers need to accept this.

 

If you take something like KDE/Gnome we have lots of standards but libraries get put in convenient places for each distro instead of just sticking to defaults. In the end neither KDE nor Gnome are linux apps, they are also Solaris or BSD apps ... like much of linux it is shared.

 

If KDE define a set of install locations then distro's should follow them and accomadate them not alter them to fit.

Unfortunately we are now on version xxxx of various libs and things which means that deps have been built on other deps etc. etc.

 

Many distro's are working on the same things with different tools (in terms of config) and duplicating the efforts and in many cases instead of expanding the base are replacing parts of it.

 

What should be done is distro specific tools like MCC/YaST need rewriting to use standards set tby the developers of the apps not change the standards to fit into the userspace config tools. These tools need to be optional NOT embedded so for instance if you want to deinstall YaST it should just be as easy as deinstalling and using whatever tool you want to configure things ...

 

Again IMHO the distro's have tried to use userspace tools as a loyalty card ... and this prevents using for instance one set of config tools in another distro ... I know Suse opensourced YaST but this is again another problem! They are trying to promote thier way as THE way...and of course noone will follow.

 

IMHO the WAY is the app writers way... even if the locations seem stupid then it was the developers choice.

I mean seriously in the early days we had a /var/ and /etc and people just used them... it ewasn't until dsistro's started moving stuff about that incompatibilities became suchg a big problem.

 

Now for example we have /etc/samba (or not) and the way to make sure everyone has the same is to take the location that a unedited tar install would take.

 

Just a silly example but take the Mandriva start icon... it shouldn't be renamed and comiled in its just plain messing with the developers wishes. It might seem insignificant but it is just one example of hundreds of thousands of tiny customisation made purely for the sake of customisation... if mandriva want their own icon then it should be part of their theme not hard coded.. just my 2c ...

Think what this does, iot means lots of themes don't work fully as the writer meant then to.. and people then repackage the theme specially for mandrake...

this is just silly ... surely a RPM a Deb and a tgz should suffice? or better just a .tgz with the build options set for packagers to just make it an RPM or DEB..?

 

In many cases I think what needs to change is that distro's need to realise they are just packagers of other peoples work adding value on top NOT the people to decide where that package gets put... if this is followed then we are only left with fixing libs etc. which is the second part of the problem...

 

A good example rather than bad is urpmi ... which builds on top of rpm...and hence the two still work together and retain compatibility ... but distro writers have got to become more flexible with accepting developers wishes and then let developers follow the standards and not alter it ....

 

if you look at other opensource projects outside linux you can see for instance Joomla .. excellent app with its themes and stuff which is OS independant NOW if we could just get all the distro's using apache as apache define then linux Joomla installs could be added to using linux specific tools because the apache stuff would be all in the same place.

 

The situation now is that distro's will put apache where they see fit and this means third party tools need configuring for the distro... to me this is bacwards.. the distro's and third party people should be making the tools compatible with apache!

[iphitus]

It would be good for it to be implemented but the problem seems to be too many camps.

On one hand you have the Suse people who have a highly modified system with all sorts of links into YaST and at the other end the LFS or arch's who have their /etc

 

... but all of this is IMHO missing the point.

All distros have their config in /etc. Yes, even Suse and Mandrake. The difference is that SuSE and mandrake provide a nice GUI over the top. If you wanted though, you could quite easily just edit the files yourself as you would on Arch or Debian or any other distro.

 

The real standardisation needs to come from real developers not distro hackers and the distro hackers need to accept this.

distro developers or application developers?

 

If you take something like KDE/Gnome we have lots of standards but libraries get put in convenient places for each distro instead of just sticking to defaults. In the end neither KDE nor Gnome are linux apps, they are also Solaris or BSD apps ... like much of linux it is shared.

 

If KDE define a set of install locations then distro's should follow them and accomadate them not alter them to fit.

Unfortunately we are now on version xxxx of various libs and things which means that deps have been built on other deps etc. etc.

 

Where software is installed is irrelevant to a certain extent. Arch installs kde to /opt/kde. I can easily install a kde application to /usr/ or /home/iphitus/stuff, and it will operate correctly.

 

Many distro's are working on the same things with different tools (in terms of config) and duplicating the efforts and in many cases instead of expanding the base are replacing parts of it.

 

What should be done is distro specific tools like MCC/YaST need rewriting to use standards set tby the developers of the apps not change the standards to fit into the userspace config tools. These tools need to be optional NOT embedded so for instance if you want to deinstall YaST it should just be as easy as deinstalling and using whatever tool you want to configure things ...

 

the thing is, there is no single set standard configuration setup. each distro has their own implementation. there is no standard. there is no standard networking scripts setup, there is no standard init process. You're looking for something that doesnt exist, and quite frankly, most likely will not. If one we're started, it'd be split pretty quickly as each distro tries to do it the best way to suit the distro's needs.

 

Again IMHO the distro's have tried to use userspace tools as a loyalty card ... and this prevents using for instance one set of config tools in another distro ... I know Suse opensourced YaST but this is again another problem! They are trying to promote thier way as THE way...and of course noone will follow.

 

IMHO the WAY is the app writers way... even if the locations seem stupid then it was the developers choice.

I mean seriously in the early days we had a /var/ and /etc and people just used them... it ewasn't until dsistro's started moving stuff about that incompatibilities became suchg a big problem.

 

Now for example we have /etc/samba (or not) and the way to make sure everyone has the same is to take the location that a unedited tar install would take.

samba's configs have resided there on every distro i've tried. same for sshd, and countless other things. it's stuff liike what I mentioned before such as init scripts and networking which have no standard scripts to base anything off.

 

Just a silly example but take the Mandriva start icon... it shouldn't be renamed and comiled in its just plain messing with the developers wishes. It might seem insignificant but it is just one example of hundreds of thousands of tiny customisation made purely for the sake of customisation... if mandriva want their own icon then it should be part of their theme not hard coded.. just my 2c ...

Think what this does, iot means lots of themes don't work fully as the writer meant then to.. and people then repackage the theme specially for mandrake...

this is just silly ... surely a RPM a Deb and a tgz should suffice? or better just a .tgz with the build options set for packagers to just make it an RPM or DEB..?

compiling it in is an act of stupidity on mandrake's behalf. it should just be set as part of a theme.

 

In many cases I think what needs to change is that distro's need to realise they are just packagers of other peoples work adding value on top NOT the people to decide where that package gets put... if this is followed then we are only left with fixing libs etc. which is the second part of the problem...

packages provide the --prefix option so that they can be put where people want them. I dont see the harm in having things in different places.

 

A good example rather than bad is urpmi ... which builds on top of rpm...and hence the two still work together and retain compatibility ... but distro writers have got to become more flexible with accepting developers wishes and then let developers follow the standards and not alter it ....

 

if you look at other opensource projects outside linux you can see for instance Joomla .. excellent app with its themes and stuff which is OS independant NOW if we could just get all the distro's using apache as apache define then linux Joomla installs could be added to using linux specific tools because the apache stuff would be all in the same place.

 

The situation now is that distro's will put apache where they see fit and this means third party tools need configuring for the distro... to me this is bacwards.. the distro's and third party people should be making the tools compatible with apache!

what if people dont like apache? I prefer lighttpd for example...

 

explain to me why having files in different places is such a bad thing. Even if they were in the same places, packages would not be compatible across distros because of the different versions, different compilers, different libc's, different package formats, different package naming setups, different compilation options, different ways of doing things.

 

There's better ways of improving things. Like the fd.o standards, like improving compatibility between kde and gnome, like improving distribution's usability. Sorry, but a user shouldnt be sent straight to the command line to configure their urpmi mirrors. I think that's something mandrake ought to be ashamed of - not providing automatic configuration of urpmi mirrors.

 

James

[Gowator]

All distros have their config in /etc. Yes, even Suse and Mandrake. The difference is that SuSE and mandrake provide a nice GUI over the top. If you wanted though, you could quite easily just edit the files yourself as you would on Arch or Debian or any other distro.

Nope lots of distro's have subdir's of /etc and other's don't ...

Some have a /etc/samba/smb.conf and others have a /etc/smb.conf

but wait ....

The real standardisation needs to come from real developers not distro hackers and the distro hackers need to accept this.

distro developers or application developers?

Nope distro developers are not really developers... at least not 90% of the time they are hacking code done by application developers... Im not placing one above the other I am saying that therre is a different between writing a driver or app from scratch and putting a distro together and we need both...

 

 

If you take something like KDE/Gnome we have lots of standards but libraries get put in convenient places for each distro instead of just sticking to defaults. In the end neither KDE nor Gnome are linux apps, they are also Solaris or BSD apps ... like much of linux it is shared.

 

If KDE define a set of install locations then distro's should follow them and accomadate them not alter them to fit.

Unfortunately we are now on version xxxx of various libs and things which means that deps have been built on other deps etc. etc.

 

Where software is installed is irrelevant to a certain extent. Arch installs kde to /opt/kde. I can easily install a kde application to /usr/ or /home/iphitus/stuff, and it will operate correctly.

Usually... however what if I write my app to config a part of KDE... I need to know arch has put it in somewhere else ... and yes i can pick up on flags but there are far morte apps than distro's, especially if you boil down the genology of the distro's so knoppix and kanotix are both really Debian and PCLinuxOS is really mandriva with bells and whistles.

 

And as I mentioned not all the software is linux specific, lots is *nix, *bad too.

 

Many distro's are working on the same things with different tools (in terms of config) and duplicating the efforts and in many cases instead of expanding the base are replacing parts of it.

 

What should be done is distro specific tools like MCC/YaST need rewriting to use standards set tby the developers of the apps not change the standards to fit into the userspace config tools. These tools need to be optional NOT embedded so for instance if you want to deinstall YaST it should just be as easy as deinstalling and using whatever tool you want to configure things ...

 

the thing is, there is no single set standard configuration setup. each distro has their own implementation. there is no standard. there is no standard networking scripts setup, there is no standard init process. You're looking for something that doesnt exist, and quite frankly, most likely will not. If one we're started, it'd be split pretty quickly as each distro tries to do it the best way to suit the distro's needs.

Well for many apps there is .. its the default which is built in... from the developers tarball.

The init process is a good example but there is really only two variants. The point Im trying to make is the distro's have created their own problem for this, i don't think deliberatly but just through time. So if for example you take one package in KDE it needs to be put into whereever and then every other deps needs to know too.

What Im saying is if the devels spent time making the distro work round the packages and apps then their time would be better spent overall. I realise it is a little late for this but LSB will be no different anbd cause the same headaches at first...

 

Again IMHO the distro's have tried to use userspace tools as a loyalty card ... and this prevents using for instance one set of config tools in another distro ... I know Suse opensourced YaST but this is again another problem! They are trying to promote thier way as THE way...and of course noone will follow.

 

IMHO the WAY is the app writers way... even if the locations seem stupid then it was the developers choice.

I mean seriously in the early days we had a /var/ and /etc and people just used them... it ewasn't until dsistro's started moving stuff about that incompatibilities became suchg a big problem.

 

Now for example we have /etc/samba (or not) and the way to make sure everyone has the same is to take the location that a unedited tar install would take.

samba's configs have resided there on every distro i've tried. same for sshd, and countless other things. it's stuff liike what I mentioned before such as init scripts and networking which have no standard scripts to base anything off.

Init scripts are another matter .. some apps are quirky like qmail... of course you can compile with a --config_dir but if what we want eventually is interoperability across distros with minimum work then let it be and do the work to make the distro work with it not change the app for the distro...

 

Just a silly example but take the Mandriva start icon... it shouldn't be renamed and comiled in its just plain messing with the developers wishes. It might seem insignificant but it is just one example of hundreds of thousands of tiny customisation made purely for the sake of customisation... if mandriva want their own icon then it should be part of their theme not hard coded.. just my 2c ...

Think what this does, iot means lots of themes don't work fully as the writer meant then to.. and people then repackage the theme specially for mandrake...

this is just silly ... surely a RPM a Deb and a tgz should suffice? or better just a .tgz with the build options set for packagers to just make it an RPM or DEB..?

compiling it in is an act of stupidity on mandrake's behalf. it should just be set as part of a theme.

 

Well that is what I mean... except this is kinda trivial and cosmetic but that is why I chose it as an example.

The work done is just counter-productive .. to me its obvious if someone chooses a new theme then they want to change the look n feel... but the main thrist of what Im saying is now every developer making a mandrake RPM has to take this into consideration and bastardise the theme.

wouldn't it be better to have the .tgz and then build the deb or rpm ?

 

 

In many cases I think what needs to change is that distro's need to realise they are just packagers of other peoples work adding value on top NOT the people to decide where that package gets put... if this is followed then we are only left with fixing libs etc. which is the second part of the problem...

packages provide the --prefix option so that they can be put where people want them. I dont see the harm in having things in different places.

Its not harm its just wasted effort on everyone else building on those ... like someone packaging a theme for distroX ... hence we have kdetheme X for Suse another version for Mandy and another FC...

 

the way linux as a whole works is collaborative effort and if i want to repackage the apps own config tool for instance I have to also add the --prefix ... there is little reason tyhe Suse RPM shouldn't work on the Mandrake box and FC box except they have the --prefix.

What Im saying is 90% of the code is not written by distro devs/hackers but by others, many of whom might use *bsd or *nix... and to be honest the more important and fundamental the code the more likely .... take cdrecord for example. The very low level apps and libs on which many others depend are not linux specific.

 

 

A good example rather than bad is urpmi ... which builds on top of rpm...and hence the two still work together and retain compatibility ... but distro writers have got to become more flexible with accepting developers wishes and then let developers follow the standards and not alter it ....

 

if you look at other opensource projects outside linux you can see for instance Joomla .. excellent app with its themes and stuff which is OS independant NOW if we could just get all the distro's using apache as apache define then linux Joomla installs could be added to using linux specific tools because the apache stuff would be all in the same place.

 

The situation now is that distro's will put apache where they see fit and this means third party tools need configuring for the distro... to me this is bacwards.. the distro's and third party people should be making the tools compatible with apache!

what if people dont like apache? I prefer lighttpd for example...

 

explain to me why having files in different places is such a bad thing. Even if they were in the same places, packages would not be compatible across distros because of the different versions, different compilers, different libc's, different package formats, different package naming setups, different compilation options, different ways of doing things.

 

if they want a different http server so what? At the moment the options are make it for a platform (linux/bsd/nix) then specific for a app (apache/lighthttpd) then for the distro ...

The example quoted is php coded so platform independant (presuming php is configured the same) its also depends on mysql etc. etc.

What Im saying is cut down the options... put it where the developers tested it because they probably have tools that expect it...

Each combination increases the config exponentially ... in the case I mentioned the need php/mysql (v3-5) I think apache but perhaps not... and each distro might have different configs that need finding and updating and a simple slip will render it unusable... these are the most common bugs i find in linux, just something that was missed building a package for a specific distro... and the work to correct it is the developer/distro or more often a volunteer packager.. My recent frustrations have been a lot to do with Ubuntu packages and trying to get replacement Debian ones ...and a very minor change renders them not compatible ..not because of libs or lib versions but because of trivialites. Add a chroot'd IA32 in a X64 and you add another level.

There's better ways of improving things. Like the fd.o standards, like improving compatibility between kde and gnome, like improving distribution's usability.

 

James

KDe and Gnome are getting their acts together (literally) and that is great.... the next step for me is to standardise Gnome/KDE config's...

Instead of distro's putting effort into making their tools configure the apps to work with their tools why not make them compatible?

If they add functionality then make it backwards compatible .. for example SWAT and Mandriva samba config were at some point incompatible... what I would like to see is the effort being made to build on top, not sideways... shorewall was an old example... they had an excellent config utility that just was incompatible with mandrake's way of doing things... its a big shame because it turned many people off shorewall ...

Wih a bit more effort mandrake could have added funtionaility and made it backwards compatible ... and then when the application changes they have less work to do ...

The impression i get is that the distro packagers end up chasing their tails on changes they made without thinking what happens when the app itself fundamentally changes. Ubuntu is a great example... for all they have added useability to Debian they have also lost compatibility and not just over lib versions...

 

Now when Debian changes something they have to rebuild and repackage according to those changes and these changes will affect the next release and the one after that.

 

I think the worst aspect is many distro's provide these tools as a way of lock-in. Certainly Mandriva and Suse put effort into making stuff incompatible just for the sake of it which is a waste of programmers effort.

In summary LSB isn't bad but I think its upside down... instead of dictating the standards they should take the standards that evolved... I mean /etc/ doesn't *need* to be called /etc but hey its here... and sticking config files in /var or /usr is silly just for the sake of it ?

 

Sorry, but a user shouldnt be sent straight to the command line to configure their urpmi mirrors. I think that's something mandrake ought to be ashamed of - not providing automatic configuration of urpmi mirrors.

Well depends on the user... I think it should be open and the config files in the same place (course only Mandrriva uses urmpi but that's the example) and I find it incredible that perhaps the most important part of Mandriva (certainly what defines it) is not only so badly done but also not even really drawn attention to.

How many noobs come here having problems compiling XX from source ?

But this is another example...

90% of the problems with comiling from source from mandriva or Debian are having to switch the --prefix...

Finding all the deps is prety easy with a good ./configure telling you... the problem is I have done this and then found packages x,y,z needs to be installed .. and it is installed its just not where the ./config thought it was.

 

A example from yesterday was comiling the wacom drivers for xorg.. needs tk ... x,y,z and a,b,c as well and I had everything installed I just had to spend 2-3 hours finding them all and setting compile flags.

 

and ... just to make me look silly....

the pre-built driver (for 6.9) actually worked once I copied it to the new xorg7 modules directory ...

No library incompatibilites or missing symbols... just the wrong directory

 

Now the question exists for a distro... do they move the Xorg directories back the the old xorg6 and previous Xfree86 dirs to work with pre-existing tools OR update the tools to the new (to me more logical) Xorg dir's?

 

Yes they can move it and they will need to rewrite 1001 other packages too every Xorg patch ... or change it once and then build on it?

 

I think the latter... Wacom are nice enough to release a linux driver as opensource... heck I think that is a good start :D but now they will need to make install scripts for different distro's that move the location of the modules. This is my main reason for thinking the disro's have to change because the companies releasing drivers are doing us a favour in terms of market share... I think its better the distro's play to them than expect them to make install scripts for different distro's.

 

With kernel 2.6+ and modular drivers and now xorg7 and modular drivers I think this is more important. This is where a manufacturer can write a single driver and have it dynamically loaded not monolithically compiled into the kernel or XFree ...

 

in a way it encompasses software too. Xorg loads the fonts (when it finds them) and the location has changed too :D however it would be nice for say firefox to rely on certain fonts being found.

 

I honestly beleive it will reduce trivial work done by devels... which most devels find boring and encourage cross distro movement