[gentoo-user] LSB compliance
Hello, Alright, I've looked through the mailing list archive and read last year's discussion on the LSB. The main conclusion was that Gentoo wasn't LSB compliant because: 1) LSB requires the use of RPMs. 2) KDE (and maybe Gnome) are in a different directory. Changing this would conflict with our ability to install both kde2 and kde3 at the same time. With respect to (1), I don't think that's quite true. I read an article a few days ago by one of the LSB members who said that the LSB doesn't require distros to use RPM as their package system. Rather, it requires them to be *able* to install RPMs. He gave the example that Debian's "alien" program fills this requirement. If this is correct, we could simply have an equivalent of "alien" for Gentoo. With respect to (2), I must say I don't really understand the problem. If the Gentoo has KDE in /usr/kde/2 and /usr/kde/3, and LSB doesn't allow /usr/kde, why don't we just move /usr/kde to /usr/share, so we would make: /usr/share/kde/2 /usr/share/kde/3 I'm sure that this question just demonstrates my ignorance of LSB and Gentoo, but heck, asking is the only way I'll learn. -- Daniel Carrera Graduate Teaching Assistant. Math Dept. University of Maryland. (301) 405-5137 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
Daniel Carrera <[EMAIL PROTECTED]> writes: [ ... ] > With respect to (1), I don't think that's quite true. I read an > article a few days ago by one of the LSB members who said that the > LSB doesn't require distros to use RPM as their package system. > Rather, it requires them to be *able* to install RPMs. He gave the > example that Debian's "alien" program fills this requirement. If > this is correct, we could simply have an equivalent of "alien" for > Gentoo. converting a binary rpm to an ebuild is doable. but only to the extent of minor dependency-checking and tracking installed files. maybe someone feels like a masochist and "fixes this" sometime. > With respect to (2), I must say I don't really understand the > problem. If the Gentoo has KDE in /usr/kde/2 and /usr/kde/3, and > LSB doesn't allow /usr/kde, why don't we just move /usr/kde to > /usr/share, so we would make: > > /usr/share/kde/2 > /usr/share/kde/3 because that's misuse of /usr/share. from: http://www.pathname.com/fhs/2.2/fhs-4.11.html> # The /usr/share hierarchy is for all read-only architecture # independent data files. in short, the FHS and LSB do not produce a solution for the problem. it's more defined as a non-issue, and you get pointed to /opt -- which according to the FHS doesn't fit either Gnome or KDE anyway. > I'm sure that this question just demonstrates my ignorance of LSB > and Gentoo, but heck, asking is the only way I'll learn. I've heard that reading also helps. :-) -- Terje -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
> converting a binary rpm to an ebuild is doable. but only to the > extent of minor dependency-checking and tracking installed files. > maybe someone feels like a masochist and "fixes this" sometime. There's no need to fix anything. As long as an RPM can get installed, the LSB doesn't care. > in short, the FHS and LSB do not produce a solution for the problem. > it's more defined as a non-issue, and you get pointed to /opt -- > which according to the FHS doesn't fit either Gnome or KDE anyway. Why doesn't /opt work? I've looked at the FHS section on /opt and I don't see what's wrong with /opt/gnome and /opt/kde. -- Daniel Carrera Graduate Teaching Assistant. Math Dept. University of Maryland. (301) 405-5137 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
Daniel Carrera <[EMAIL PROTECTED]> writes: > > converting a binary rpm to an ebuild is doable. but only to the > > extent of minor dependency-checking and tracking installed files. > > maybe someone feels like a masochist and "fixes this" sometime. > > There's no need to fix anything. As long as an RPM can get > installed, the LSB doesn't care. I care. :-) I'd like to be able to install / uninstall the rpm via emerge and have emerge track its files. an alien for emerge if you like. > > in short, the FHS and LSB do not produce a solution for the > > problem. it's more defined as a non-issue, and you get pointed to > > /opt -- which according to the FHS doesn't fit either Gnome or KDE > > anyway. > > Why doesn't /opt work? I've looked at the FHS section on /opt and I > don't see what's wrong with /opt/gnome and /opt/kde. because stuff in /opt is supposed to be static packages, not dependent on anything else on the system, least of all other packages (heck, formally even depending on glibc is bad). this also works the other way around, no packages should ideally depend on anything located in /opt. both Gnome and KDE break this both ways. they depend on stuff in / or /usr, and other packages depend on KDE or Gnome libraries. -- Terje -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
On Mon, Mar 03, 2003 at 05:30:26AM +0100, Terje Kvernes wrote: > > Why doesn't /opt work? I've looked at the FHS section on /opt and I > > don't see what's wrong with /opt/gnome and /opt/kde. > > because stuff in /opt is supposed to be static packages, not > dependent on anything else on the system, least of all other > packages (heck, formally even depending on glibc is bad). this also > works the other way around, no packages should ideally depend on > anything located in /opt. Oh. The full magnitude of the problem suddenly dawns on me. /opt is bad because it's contents are not supposed to be dependent on anything else. /usr/local is bad because it's meant for non-distribution packages. /usr/share is bad because it's meant for read-only data. That only leaves /usr, but that conflicts with FHS. I guess that all that can be done is change the FHS. I'll post an email to the LSB-Future mailing list tomorrow. They are currently discussing what to do about KDE and Gnome. Perhaps a not-too-distant version of the LSB will offer a solution. Thanks for clarifying all this. -- Daniel Carrera Graduate Teaching Assistant. Math Dept. University of Maryland. (301) 405-5137 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
Daniel Carrera <[EMAIL PROTECTED]> writes: > On Mon, Mar 03, 2003 at 05:30:26AM +0100, Terje Kvernes wrote: > > > because stuff in /opt is supposed to be static packages, not > > dependent on anything else on the system, least of all other > > packages (heck, formally even depending on glibc is bad). this > > also works the other way around, no packages should ideally depend > > on anything located in /opt. > > Oh. The full magnitude of the problem suddenly dawns on me. I know the feeling. in this matter it's quite depressing. > /opt is bad because it's contents are not supposed to be dependent > on anything else. /usr/local is bad because it's meant for > non-distribution packages. /usr/share is bad because it's meant for > read-only data. That only leaves /usr, but that conflicts with FHS. correct. well, /usr/share is also supposed to be architecture independent. ey, we'd solve all this if we'd rewrite all the KDE and Gnome libraries in POSIX-compliant sh. :-) > I guess that all that can be done is change the FHS. I'll post an > email to the LSB-Future mailing list tomorrow. They are currently > discussing what to do about KDE and Gnome. Perhaps a > not-too-distant version of the LSB will offer a solution. I'm honestly not holding my breath. the advocacy I hear from people who work with FHS and LSB basically point to "KDE and Gnome are broken", or "do you really need several versions of KDE in your distribution". > Thanks for clarifying all this. you're welcome. by the way, I'm probably visiting my girlfriend at UMD in late March. hope the snow is gone by then. :-) -- Terje -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
On Sunday 02 March 2003 09:44 pm, Daniel Carrera wrote: > On Mon, Mar 03, 2003 at 05:30:26AM +0100, Terje Kvernes wrote: > > > Why doesn't /opt work? I've looked at the FHS section on /opt and I > > > don't see what's wrong with /opt/gnome and /opt/kde. > > > > because stuff in /opt is supposed to be static packages, not > > dependent on anything else on the system, least of all other > > packages (heck, formally even depending on glibc is bad). this also > > works the other way around, no packages should ideally depend on > > anything located in /opt. > > Oh. The full magnitude of the problem suddenly dawns on me. > > /opt is bad because it's contents are not supposed to be dependent on > anything else. /usr/local is bad because it's meant for non-distribution > packages. /usr/share is bad because it's meant for read-only data. That > only leaves /usr, but that conflicts with FHS. > > I guess that all that can be done is change the FHS. I'll post an email > to the LSB-Future mailing list tomorrow. They are currently discussing > what to do about KDE and Gnome. Perhaps a not-too-distant version of the > LSB will offer a solution. > > Thanks for clarifying all this. I wish you luck. I tried this at least a year ago, and I got no response whatsoever. My general impression has been that the FHS/LSB bunch are more interested in superimposing their narrow view of the world on the world than actually solving problems. -- Collins Richey - Denver Area Athlon-XP gentoo 1.4_rc2 kde 3.1 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
/opt is bad because it's contents are not supposed to be dependent on anything else. /usr/local is bad because it's meant for non-distribution packages. I'm curious...why is it so much of a problem to put it in /usr/local ? I am not that familiar with FHS or LSB, so please forgive me if this sounds totally nuts. On my openbsd machine, they have decided /usr/local is for anything that is "not essential to the base system." To their way of thinking, anything besides the base system (perl, libs, ssh, etc) is considered a "non-distribution package." Why do KDE or GNOME _not_ fall into this category? Ted -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
"Ted Goodridge, Jr" <[EMAIL PROTECTED]> writes: > > /opt is bad because it's contents are not supposed to be dependent > > on anything else. /usr/local is bad because it's meant for > > non-distribution packages. > > I'm curious...why is it so much of a problem to put it in > /usr/local? http://www.pathname.com/fhs/2.2/fhs-4.9.html > > I am not that familiar with FHS or LSB, so please forgive me if > this sounds totally nuts. well, then read the FHS. :-) > On my openbsd machine, they have decided /usr/local is for anything > that is "not essential to the base system." To their way of > thinking, anything besides the base system (perl, libs, ssh, etc) is > considered a "non-distribution package." that's OpenBSD. not Linux. personally I find it totally broken that they separate out their ports tree as something other than "system software". this is why we have /usr. this is of course also annoying since your basesystem is _not_ maintained via ports. how then do you do the equivalent of "emerge --update glibc"? anyhow, the issue is more the definition of "local" software. OpenBSD uses the term as "stuff installed apart from the core stuff we deem that you have to have". Linux defines "local" as "whatever the sysadmin installs apart from what the distribution provides". for Gentoo this is even more true than ever. the question then comes of course, where do you install your local software on OpenBSD? /local? which by the way is not defined in the hier (7) manpage of OpenBSD. and if you use /usr/local, what happens if you install a port that has files that collide with what you've installed on your own? > Why do KDE or GNOME _not_ fall into this category? that's nowhere near the point. KDE and Gnome are installed by a packager coming with the distribution. that makes /usr/local a big no-no. -- Terje -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
Quoting Daniel Carrera <[EMAIL PROTECTED]>: > Oh. The full magnitude of the problem suddenly dawns on me. > > /opt is bad because it's contents are not supposed to be dependent on > anything else. /usr/local is bad because it's meant for non-distribution > packages. /usr/share is bad because it's meant for read-only data. That > only leaves /usr, but that conflicts with FHS. > > I guess that all that can be done is change the FHS. I'll post an email > to the LSB-Future mailing list tomorrow. They are currently discussing > what to do about KDE and Gnome. Perhaps a not-too-distant version of the > LSB will offer a solution. Whatever solution is adopted should ideally provide a *general* solution to this. Enlightenment, TheNextNewHugeProject, and any number of other things could benefit as well. Indeed, it would be nice if multiple versions of anything people feel they need to keep multiple versions around for could be supported. In other words, I'd be disappointed if /usr/kde, /usr/qt, and /usr/gnome were simply added to the 'exceptions list' for /usr (joining its only current member, 'X11R6'). A scalable solution, mappable to any future large project, is what IMHO is needed...the easiest and most obvious possibility being the addition of a directory such as /usr/pkg, which in turn can contain /usr/pkg/kde/3, /usr/pkg/gnome/2.2, /usr/pkg/qt/3, and so on. my 2 cents, Jean. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
On Monday 03 March 2003 01:43 pm, [EMAIL PROTECTED] wrote: > Quoting Daniel Carrera <[EMAIL PROTECTED]>: > > Oh. The full magnitude of the problem suddenly dawns on me. > > > > /opt is bad because it's contents are not supposed to be dependent on > > anything else. /usr/local is bad because it's meant for non-distribution > > packages. /usr/share is bad because it's meant for read-only data. That > > only leaves /usr, but that conflicts with FHS. > > > > I guess that all that can be done is change the FHS. I'll post an email > > to the LSB-Future mailing list tomorrow. They are currently discussing > > what to do about KDE and Gnome. Perhaps a not-too-distant version of the > > LSB will offer a solution. > > Whatever solution is adopted should ideally provide a *general* solution to > this. Enlightenment, TheNextNewHugeProject, and any number of other things > could benefit as well. Indeed, it would be nice if multiple versions of > anything people feel they need to keep multiple versions around for could > be supported. > > In other words, I'd be disappointed if /usr/kde, /usr/qt, and /usr/gnome > were simply added to the 'exceptions list' for /usr (joining its only > current member, 'X11R6'). A scalable solution, mappable to any future > large project, is what IMHO is needed...the easiest and most obvious > possibility being the addition of a directory such as /usr/pkg, which in > turn can contain /usr/pkg/kde/3, /usr/pkg/gnome/2.2, /usr/pkg/qt/3, and so > on. > This is all fine and dandy, but you need to direct this to LSB, and rational logic doesn't seem to go very far with that group. -- Collins Richey - Denver Area Athlon-XP gentoo 1.4_rc2 kde 3.1 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
On Mon, Mar 03, 2003 at 02:43:27PM -0600, [EMAIL PROTECTED] wrote: > Whatever solution is adopted should ideally provide a *general* solution to > this. Enlightenment, TheNextNewHugeProject, and any number of other things > could benefit as well. Indeed, it would be nice if multiple versions of > anything people feel they need to keep multiple versions around for could be > supported. > > In other words, I'd be disappointed if /usr/kde, /usr/qt, and /usr/gnome were > simply added to the 'exceptions list' for /usr (joining its only current member, > 'X11R6'). A scalable solution, mappable to any future large project, is what > IMHO is needed...the easiest and most obvious possibility being the addition of > a directory such as /usr/pkg, which in turn can contain /usr/pkg/kde/3, > /usr/pkg/gnome/2.2, /usr/pkg/qt/3, and so on. I understand your argument, and I agree with you. However, this misses the point of the LSB as it currently stands. The point of the LSB is not to create "the best" standard, but to create _the_least_OBTRUSIVE_ one. In other words, the idea is to make it as close to what ever most people do already while at the same time being useful. This makes it easier for distributions to comply to the standard, and hence it makes it more likely that they'll take the time to become compliant. Once that's achieved, we can, in steps, proceed to make the standard better. In other words, though I agree that your idea of adding /usr/pkg and making Gnome, KDE, etc lie in it, is likely the best hierarchy, there are other considerations why the LSB should not implement it (i.e. no one would be compliant). There is an LSB-Future project. I wonder if they'll consider this ide. Because it *is* a good idea. -- Daniel Carrera Graduate Teaching Assistant. Math Dept. University of Maryland. (301) 405-5137 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
why not /gui George (running and ducking for cover) > > Whatever solution is adopted should ideally provide a *general* solution > > to this. Enlightenment, TheNextNewHugeProject, and any number of other > > things could benefit as well. Indeed, it would be nice if multiple > > versions of anything people feel they need to keep multiple versions > > around for could be supported. > > > > In other words, I'd be disappointed if /usr/kde, /usr/qt, and /usr/gnome > > were simply added to the 'exceptions list' for /usr (joining its only > > current member, 'X11R6'). A scalable solution, mappable to any future > > large project, is what IMHO is needed...the easiest and most obvious > > possibility being the addition of a directory such as /usr/pkg, which in > > turn can contain /usr/pkg/kde/3, /usr/pkg/gnome/2.2, /usr/pkg/qt/3, and > > so on. > > This is all fine and dandy, but you need to direct this to LSB, and > rational logic doesn't seem to go very far with that group. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
On Mon, Mar 03, 2003 at 02:39:00PM -0700, Collins wrote: > This is all fine and dandy, but you need to direct this to LSB, and rational > logic doesn't seem to go very far with that group. You are being very unfair. As much as they'd like to, the LSB *can not* simply decide on the most rational system. They have to decide on the least *obtrusive* system which is still complete enough to be meaningful. We need to make it as easy as possible for most distros to become compliant while at the same time making compliance useful for something. It's not an easy balance, and it is a balance that is almost guaranteed to *not* produce the best system possible. The problem is that designing the best system possible would require such an effort for distributions that it would impede the acceptance of Linux. It's best to start with the simplest thing, and then slowly move to make it more complete and if possible, closer to the ideal. This is the kind of thing that is discussed in the LSB-Future mailing list. -- Daniel Carrera Graduate Teaching Assistant. Math Dept. University of Maryland. (301) 405-5137 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
On Monday 03 March 2003 02:48 pm, Daniel Carrera wrote: > On Mon, Mar 03, 2003 at 02:39:00PM -0700, Collins wrote: > > This is all fine and dandy, but you need to direct this to LSB, and > > rational logic doesn't seem to go very far with that group. > > You are being very unfair. As much as they'd like to, the LSB *can not* > simply decide on the most rational system. They have to decide on the > least *obtrusive* system which is still complete enough to be meaningful. > We need to make it as easy as possible for most distros to become > compliant while at the same time making compliance useful for something. > It's not an easy balance, and it is a balance that is almost guaranteed to > *not* produce the best system possible. The problem is that designing the > best system possible would require such an effort for distributions that > it would impede the acceptance of Linux. > > It's best to start with the simplest thing, and then slowly move to make > it more complete and if possible, closer to the ideal. This is the kind > of thing that is discussed in the LSB-Future mailing list. IMHO, b.s. There is nothing inherently "obtrusive" or difficult to implement about a rational system that provides a simple but effective directory structure for multiple versions of major packages. There is no more effort for vendors in supplying major packages in a /usr/pkg directory, for example, than in scattering the appropriate files all over the /usr structure. It's just a minor restructuring of the much beloved RPM specs, and extension to $PATH, etc. Sorry, that dog won't hunt! -- Collins Richey - Denver Area Athlon-XP gentoo 1.4_rc2 kde 3.1 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
On Mon, Mar 03, 2003 at 04:41:51PM -0700, Collins wrote: > IMHO, b.s. Easy now, no need to offend. > There is nothing inherently "obtrusive" or difficult to implement about a > rational system that provides a simple but effective directory structure for > multiple versions of major packages. There is no more effort for vendors in > supplying major packages in a /usr/pkg directory, for example, than in > scattering the appropriate files all over the /usr structure. It's just a > minor restructuring of the much beloved RPM specs, and extension to $PATH, > etc. Actually, yes there is. For one, there is backwards compatibility. Programs currently expect to find certain things in certain places. If you change the directory structure, then an older RPM won't work on a newer system. Also, unless everyone changes at precisely the same time (which is guaranteed not to happen), then an RPM for one system won't work on another. On a secondary level, consider that there is a very large number of packages to change. This problem is magnified when you look at the large number of distributions that exist today. Not only them, but also any other vendor of Linux software (e.g. Ximian, IBM, the Kompany). The LSB is only useful if the VAST majority of them make the change. If the changes are so great that they'll break much compatibility, no one is going to want to be the first to change. Thus, change will only occur if they all agree to do it simultaneously. Getting such concensus from such a large number of people is very difficult. Even after that's done, you still have the problem of older packages. No, the smartest approach is to *first* make the LSB as close as possible to whatever everyone does right now. Once almost everyone is in LSB, you can move them, in steps, towards a more optimal system. -- Daniel Carrera Graduate Teaching Assistant. Math Dept. University of Maryland. (301) 405-5137 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] LSB compliance
On Monday 03 March 2003 04:59 pm, Daniel Carrera wrote: > No, the smartest approach is to *first* make the LSB as close as possible > to whatever everyone does right now. Once almost everyone is in LSB, you > can move them, in steps, towards a more optimal system. Yes, and an even smarter approach is to allow for minor deviations like KDE where it makes sense. I only started into this thread because of the ... (publishable words fail me) who is so violently apposed to gentoo because of the LSB crap (MO). Way too many LSBers (once again MO) are way too inflexible. Linux has always been about flexibility, and when you make a standard a religion it stops being as useful. Also, I doubt that the LSB will ever expand towards a more optimal system. It's designed to be a straight jacket, and it will probably remain that way. -- Collins Richey - Denver Area Athlon-XP gentoo 1.4_rc2 kde 3.1 -- [EMAIL PROTECTED] mailing list
