DJB's page doesn't say you have to disconnect from IPv4 to be on IPv6. His point is that no sane person would disconnect from IPv4 as long as IPv6 addresses are less useful.
Right now, everyone is on IPv4 and only some are on IPv6. So how are we going to get to the point where we can “flip the switch” and get rid of IPv4? The only way is to convince everyone to be on both IPv4 and IPv6, for at least a short period. So far this hasn't worked because, surprise, people aren't that eager to spend extra effort, time, and money for a benefit that may happen far in the future, or may not even happen at all.
DJB's idea is much more conservative: make IPv4 a subset of IPv6, so that everyone gets IPv6 for free when they upgrade their software. By doing this, you get the expanded address space but you lose all the other touted benefits of IPv6. It's a sure-thing because people need to upgrade software eventually, and when they do they automatically become IPv6-enabled whether they like it or not. There's nothing to turn on or off—it all just works.
The IETF isn't taking DJB's idea seriously because they think they can have their cake and eat it, too. They really want the expanded address space, which is crucial, but they're trying to piggyback a bunch of other non-crucial improvements on top. And they're losing on everything. I'm not saying these non-crucial improvements aren't nice—it's just, come on, let's be realistic here and do things one step at a time...
Yes. Software developers should adopt/package for their software, giving their users atomic upgrades and downgrades, and easy side-by-side installations. Also see sptools and spftools for managing these types of packages.
From the article: “Hackers should be given incentives to reveal the security vulnerabilities they find in a responsible manner.”
Responsible? The security vulnerability is not the fault of the person who discovers it! It is the vendor's fault. Security will not improve if we continue to keep information secret and shield vendors from their mistakes. Security holes are not some kind of naturally-ocurring phenomena, nor are they something to hide from. They are the fault of vendors who do not invest the necessary effort to develop secure software. Publishing security holes publicly punishes these vendors, and gives them an incentive to improve their practices. Yes, there may be short-term pain as a result. But it's the only way to improve security in the long-term.
The IPv6 mess explains why a fundamental mistake on the part of the IPv6 designers has had giganitc effects on the cost of making an IPv6 Internet work in practice.
Just set up your servers with single stack IPv4/6 and listen on the v6 port, and you're done
No, I'm not “done.” I still need to
acquire my own public IPv6 address, and
announce that address in DNS alongside my public IPv4 address,
or else IPv6 clients won't be able to connect to my server.
Besides, you missed Bernstein's point. If you're asking me to configure extra options, you've already lost. His solution to the address crunch is better that the current IPv6 specification because he has come up with a way to make the transition to 16-byte addresses happen automatically as part of regular software/hardware upgrades, with no extra configuration.
What are you trying to argue? That an automatic transition would be a bad thing? That an automatic transition has higher costs associated with it than a nonautomatic transition? I suggest you reread The IPv6 mess carefully.
Where did DavyGrvy mention turning off IPv4? They work together, you know. Do even Slashdotters not understand that adding IPv6 to a network does nothing to reduce IPv4 connectivity? It's win-win.
How is it “win-win”? It costs money and effort for every administrator of a computer on a public IPv4 address to also acquire and enable a public IPv6 address. What exactly is their reward for spending time setting up useless IPv6 addresses their perfectly functional IPv4 machines?
IPv6 tunnels over IPv4. IPv4 tunnels over IPv6. Machines running IPv4 can talk to machines running IPv6. Machines running IPv6 can talk to machines running IPv4.
IPv6 still has issues, to be sure, but interoperability with IPv4 isn't one of them.
Do you realize that all this added cost and complexity could have been avoided if the IPv6 designers had simply designed the IPv6 address space as an extension to the IPv4 address space, rather than an alternative to the IPv4 address space? Interoperability with IPv4 is the single largest issue preventing adoption of IPv6. Please see The IPv6 mess for much more detail.
The showstopper with IPv6 is that it was not designed with a coherent transition plan in mind. Sure, once everyone is using IPv6 it should work fine, but making the switch from IPv4 to IPv6 has enormous costs associated with it.
The IPv6 mess by D. J. Bernstein has much more detail:
“The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
“In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other. The specifications could have defined a functionally equivalent public IPv6 address for each public IPv4 address, embedding the IPv4 address space into the IPv6 address space; but they didn't.
“This might sound like a very small mistake: after all, once IPv6 is working, we can move everything to IPv6, so who cares about IPv4? The problem is that this mistake has gigantic effects on the cost of making IPv6 work in the first place.
“In short, because of this mistake in the IPv6 design, making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address—and, for the same reasons, every administrator of a client on a public IPv4 address—has to go to extra effort to acquire and enable a public IPv6 address.
“Example of the difference: As of 2002.11, Google hasn't published IPv6 addresses for www.google.com. What exactly is Google's reward for spending time setting up useless IPv6 addresses for its perfectly functional IPv4 machines? In contrast, they've had IPv6 software for years.
“Under the current IPv6 specifications, to make the magic moment happen, not only do we have to convince a few thousand network programmers to do something with no immediate benefit, but we also have to convince millions of computer administrators to do something with no immediate benefit. This is an incredibly bad way to handle a transition.”
I suggest using the QTDIR variable to find your default location, and the linker to find your libraries
We could use search paths for everything, but getting the details right is a royal pain and people inevitably screw it up.
Demanding that my system become less functional because you don't know better than to use hard-coded pathnames is ridiculous.
Do you realize how silly this sounds? Your system is functional precisely because it uses tons of hard-coded pathnames. Ever tried changing the location of/bin/sh? How about/dev/null? What about/etc/fstab?
I'd rather live with the unmatched convenience of apt, than try to morph my system into some mix of Plan 9 and GNU/Linux.
apt is indeed a nice interface to package management; however, nothing about it is inherently tied to the FHS. It could be made to work with other package layouts.
At the end of the day, all our software is designed to work with the FHS, and no amount of fraglie automated scripts to create compatability directories for binaries, include files, library files, man pages, info pages, gstreamer elements, pam modules, iptables modules, firmware, bonobo components, gimp plugins, browser plugins, and so on ad infinitum is going to circumvent that.
You'd be surprised how at how much less work it is than you think. sp-foreign is 5268 lines of Bourne shell scripting on my system. Compare this with dpkg and all the Debian packaing infrastructure. Granted, they have different requirements and different goals, but my point is that an non-FHS system is do-able.
Mac OS X does this, too. You can't even edit/etc/passwd! And yet people absolutely *love* the Mac. So it apparently isn't "essential".
Cross-platform compatibility isn't essential from the perspective of end users, but it's essential for people who want to efficiently support software on multiple platforms. Haven't you seen how much extra effort goes into ensuring a package works correctly on OS X? I'm not talking about ports which take advantage of the platform-specific features, like Carbon Emacs. I'm talking about getting a package working on Mac that generally works fine on other UNIX variants. Chances are you won't be able to compile it out-of-the-box. Overall, countless hours are wasted just because Apple decided to rename GL/gl.h to OpenGL/gl.h and not support the standard interface. Mac users are actually suffering indirectly from the dilution of support resources, even if they don't realize it.
What's more, are any sysadmins using Debian going to stop using it because of this? Probably not. Are any Windows or Mac users going to stop considering Debian because of this? Doubtful. Changing this would make *you* happier, but otherwise not have significant effects.
Wrong. Do you realize how much extra effort is required by maintainers and third-party software vendors to support their packages on dozens of different UNIX variants? That's because most of the variants apply tweaks that make their package interfaces incompatible with other platforms. In short, they're throwing away the efficiencies of the mass markets. We'd all have better software if UNIX integrators cared about cross-platform compatibility.
It doesn't look "distinct", it looks like a UNIX nerd never realised that the world stopped being an xterm in about 1996.
LOL:)
Some reading for you, that you may become enlightened
Thanks for the links; I hadn't seen the subject discussed at length before. I'm going to look into it some more and possibly reconsider my (ab)use of the backtick:)
Ideally, I'd like to just use Unicode characters directly (not entities) for open and closed quotes, but I can't do this until I'm confident all clients are using Unicode (lots of people still use various legacy character sets ATM).
/package reuses the filesystem as the database. It provides you with all the package management features you get from traditional package managers, as well as many features they don't provide; for example, adding new files to a package, or declaring that some existing files form a package. A ``central database'' is neither necessary nor desireable.
Any program that requires QT to live in/usr/local/qt3, is *broken* in the first place.
I don't care if UNIX integrators think it's ``broken.'' The reality is upstream maintainers will choose whichever package layouts they believe are best. You are living in a fantasy world if you think that someday, every package in the universe in going to conform to the FHS. Now given this reality, we are faced with the problem of trying to make interoperability among UNIX-style systems work. The solution is for us all to stop whining and support the standard names with symlinks.
If you write your programs to #include , not "/usr/local/qt3", and to have the libqt-mt.so.3 SONAME in DT_NEEDED, rather than (ugh) hard-coding in/usr/local/lib/qt3/lib/libqt.so.3, and so on, then you don't have to know where QT's files actually are.
You're arguing that it's just fine to move files if the files are accessed with the help of search paths: $PATH, $MANPATH, $LD_LIBRARY_PATH, etc. There's no theoretical obstacle to building a complete system along these lines. But it's bad engineering: getting all the details right is a royal pain, and people inevitably screw it up. For example, what happens if you try to upgrade a ``local'' version of slrn by installing a ``system'' package? The program will be put in/usr/bin and the old one will still be in/usr/local/bin. Now users with/usr/local/bin before/usr/bin in their $PATH will invoke the old, undesireable version. Please see FHS failures for more examples.
If you are curious, you can always find out with dpkg --listfiles libqt3-mt.
What about on Red Hat? What about on SUSE? What about on the hundreds of other UNIX variants out there? Do you really think its feasible to demand that each package author be aware of where each of his dependencies lives on each different platform?
If the packages dumped all their stuff in/usr/local/$package, you would have to maintain an ever-growing list of directories in which to search for shared libraries, headers, binaries, man pages, etc.
No, you don't. I know because I do organize my systems this way. You can use symbolic links to make the files available at their expected locations.
Something else that you'd lose the ability to do is to share out/usr/share, to make *all* the arch-independant, data in an installation available to machines on a network.
It is wrong for sharability to determine the name by which a file is accessed. Sharability is not constant. Names must be constant. I can simply set up symlinks like
/usr/share/qt3 ->/usr/local/lib/qt3/share
or vice versa to share arch-independent data via/usr/share.
So either we follow your route, and have everything put into/usr/local, which is fine if it's consistent, or we put it all somewhere else which is consistent. Personally, I like to know that only things I've hand-compiled go in/usr/local, rather than having it a mish-mash of official and local packages.
It's consistent within your system. The problem is now that my package can't reliably and automatically find its dependencies on all systems. Should it look in/usr, or in/usr/local? If it finds a dependency in both, which one should it use?
We need to separate the idea of name from the idea of location. Symbolic links let us do just that. You can install packages for your system in different locations depending on whether they are ``local'' or part of ``the system.'' All I'm saying is make sure they are accessible by the default names (using symlinks, if necessary).
backtick, conveniently enough, can serve as an open quote. It looks different from apostrophe, which can serve as a closing quote. This has the effect of making each type of quote distinct (i.e. you can easily tell where a quote begins and ends), whereas with typewriter quotes, the opening and closing quotes look exactly the same.
Get a better font (i.e. one with slightly curvy quotes) and it will look better to you.
Personally I can't stand Qt, but a cursory examination reveals that you can just pretend that Qt is installed to/usr/share/qt3 instead of/usr/local/qt3
If I write a program which depends on Qt, how exactly is my program supposed to know that? Am I supposed to be aware of where every UNIX-style operating system in the world has decided to put Qt, and then check all these places one by one? Or is each of my users supposed to manually enter the location for Qt, depending on his operating system?
The symlinks shipped by the Debian packages ensure compatibility with the (IME, inflexible and annoying) layout where everything is in a single directory.
As I said before, there's relatively little benefit to a package's interface being similar across all platforms (i.e., single directory). The tremendous benefit comes when the interface is exactly the same across all platforms (i.e., I can count on/usr/local/qt/include/qt.h being there).
And I don't care if you find the layout Qt's authors have chosen annoying. You're free to install Qt wherever you like on your system and then deal with the consequences. But it's ridiculous to subject all Debian users to these hassles, especially since they could be avoided by adding one measly symlink to the Debian package.
So they don't clutter up my/usr/local/ tree, a directory for things I've installed by hand, with automatically installed packages? Good for them. The Filesystem Hierarchy Standard says "The/usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated," and I'd hate to use a distribution that violated that safety.
How, pray tell, would one measly symlink
/usr/local/qt ->/usr/share/qt3
violate your ``safety''? Clutter up your precious/usr/local tree? Get a grip. If you want to install a ``local'' version of Qt later, just delete the symlink and go from there.
Why does the directory location of qt matter that much to you anyway? Fedora has it in/usr/lib/qt-3.3 and everything's working fine. In fact, I could put qt in/home/roystgnr/qt/ if I want, define QTDIR and my linker path accordingly, and unless your qt-using software is broken it should work.
The location of Qt matters to me because, if I write a program that depends on Qt, I can provide/usr/local/qt as the default location and it will Just Work for my users. I don't have to give them extra instructions on how to find out where Qt has been installed on their system and how futz around with environment variables. Do you realize how much distributions are diluting my support resources by refusing to make packages available at their default locations? Now multiply that by the number of people writing Qt applications, and you'll see why the location matters to me.
If you want to install Qt to a non-standard location like/home/roystgnr/qt, that's your problem to make it work. High-quality software would make the prefix of a Qt dependency easily configurable, anyways.
For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage
You're misunderstanding me. I'm not saying Debian shouldn't add man pages, or make the documentation for package foo available under the name/usr/share/doc/foo, or generally enhance the cross-package interface of their packages. All the power to them. What I'm saying is that if, by default, openssl installs its configuration files in/usr/local/ssl, and Debian wants to put them in/usr/lib/ssl, they should support the default location by symlinking it to the Debian-specific location. That way, people can still find them at the default location. Even if they refuse to touch/usr/local, they can at least symlink/usr/ssl to/usr/lib/ssl, so all the files are in their expected locations relative to the/usr prefix. But they flat out refuse to do that because the symlink would ``clutter up/usr and violate the FHS.'' That's what annoys me.
djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard
You're misunderstanding the purpose of/package: it's not a ``solution'' to cross-platform compatibility. In fact, DJB is strictly against modifying packages downstream to fit into/package. He proposed it as a format for upstream maintainers to adopt, if they choose. Furthermore, he's made it clear what he thinks of the FHS, but he still respects the decision of upstream maintainers who have chosen the FHS for their packages interfaces. He's not telling anyone to get rid of/usr/local/bin in favor of/command; on the contrary, he suggests you symlink everything in/command into/usr/local/bin for compatibility. Please read hispages again carefully. He's terse, but his reasoning is sound.
You couldn't be more wrong when you say Debian ``compromises'' to achieve cross-platform compatibility. In fact, they want everyone to conform to their world view; this is an uphill battle and it will never work. Different upstream authors do things differently with their packages, and they're not all going to suddenly change because Debian and the FHS are yelling at them that they're packages are ``broken.'' They choose layouts that reduce the total effort required by them to support all platforms.
But if you're an upstream maintainer, Debian will change your package's interface downstream as they see fit and make it incompatible with your upstream version. Now all the programs which depend on your upstream interface will break on Debian. So Debian will fix those programs, too, if they happen to package them. But if they don't, your users are in for headaches.
Don't get me wrong, Debian is a fantastic operating system. But there would be so many fewer headaches for users if they attempted to ``play nice'' with other systems, rather than saying ``It's the Debian way or the high way!''
An alternative is to forsake the shared library cache alltogether, and maintain an ever-growing collection of PATH, LD_LIBRARY_PATH, etc, environmental variables.
A better alternative is to make your binary depend on the absolute library path of the shared library by passing gcc the -Wl,-rpath flag. This is extremely flexible because the absolute path can be a symlink to whichever version of the library you want your binary to use.
For instance, let's say I am installing version 1.0 of foo in prefix/package/misc/foo-1.0, and I want it to depend on the default installed version of bar, 0.5. I symlink
/package/misc/bar ->/package/misc/bar-0.5
/package/misc/foo-1.0/conf ->/package/misc/bar
and I tell my binaries in foo-1.0 to always access bar.so by the absolute path
/package/misc/foo-1.0/conf/bar/lib/bar.so
(No need to consult/etc/ld.so.conf.)
Now, let's say I want to upgrade the default version of bar to 0.6, but I want foo to continue using the older version 0.5 because I know this combination is supported and known to be stable. I can simply change the symlinks to
No environment variables necessary. And you certainly don't need to ship private copy of libraries with each package.
Please tell me: How would you accomplish this scenario with an FHS-compliant system (upgrade a dependency for a given set of packages and not others)?
I know/package can seem strange at first, but once you understand it you'll see that its both simpler and more powerful than the FHS solution. If you're interested look at slashpackage-foreign. This is how I build my systems; I don't even have a file called/etc/ld.so.conf:)
Oh yeah, I symlink all commands into/command, so I only have one entry in my $PATH:) (Of course, I have/usr/bin,/usr/sbin,/usr/local/bin, and/usr/local/sbin all symlinked to/command for compatibility.)
Thanks for your comment:)
Debian is indeed a superb distro and has some fantastic tools like apt-get. But if we want compatibility across different distributions, we're not going to achieve it by trying to force every package author to fit their package into a specific mold. Linux isn't like that; different parts are maintained by different people who have different styles. We're never going to get everyone to agree on RPM/Deb/FHS/LSB/etc. But if we let the upstream package maintainer decide on the names and locations (i.e. the interface) of his own package, and we stick with it downstream, we might be able to make it work. Note that Debian could add their own FHS-ized interface to a package if they want, they just have to commit to supporting the upstream interface as well.
No, the FHS specifically prevents cross-platform compatibility. For example, if a package is installed ``locally'' on one system it will have a different interface than if it installed as part of ``the system'' on another. For example, how do we find libssl.so on an FHS-compliant system? Is it/usr/lib/libssl.so or/usr/local/lib/libssl.so, or even/opt/openssl/lib/libssl.so? The FHS ensures we will never have a simple, consistent name, like we would have if the package author madated it to be/package/host/openssl.org/openssl/libssl.so.
Sorry, as many have pointed out, I am mistaken about apachectl; indeed, it works fine in Debian. But if you want to see what I mean, look at Qt: Follow the instructions for installing from source, and you will have everything accessible under/usr/local/qt; install the Debian packages, and you will see they changed the name to/usr/share/qt3.
Sorry, I am indeed mistaken about apachectl. But, as I explained in my other reply, please look at Qt and you will see an example of how different the Debianized package is.
Slashdot Mirror
DJB's page doesn't say you have to disconnect from IPv4 to be on IPv6. His point is that no sane person would disconnect from IPv4 as long as IPv6 addresses are less useful.
Right now, everyone is on IPv4 and only some are on IPv6. So how are we going to get to the point where we can “flip the switch” and get rid of IPv4? The only way is to convince everyone to be on both IPv4 and IPv6, for at least a short period. So far this hasn't worked because, surprise, people aren't that eager to spend extra effort, time, and money for a benefit that may happen far in the future, or may not even happen at all.
DJB's idea is much more conservative: make IPv4 a subset of IPv6, so that everyone gets IPv6 for free when they upgrade their software. By doing this, you get the expanded address space but you lose all the other touted benefits of IPv6. It's a sure-thing because people need to upgrade software eventually, and when they do they automatically become IPv6-enabled whether they like it or not. There's nothing to turn on or off—it all just works.
The IETF isn't taking DJB's idea seriously because they think they can have their cake and eat it, too. They really want the expanded address space, which is crucial, but they're trying to piggyback a bunch of other non-crucial improvements on top. And they're losing on everything. I'm not saying these non-crucial improvements aren't nice—it's just, come on, let's be realistic here and do things one step at a time...
... have already been explained.
Yes. Software developers should adopt /package for their software, giving their users atomic upgrades and downgrades, and easy side-by-side installations. Also see sptools and spftools for managing these types of packages.
From the article: “Hackers should be given incentives to reveal the security vulnerabilities they find in a responsible manner.”
Responsible? The security vulnerability is not the fault of the person who discovers it! It is the vendor's fault. Security will not improve if we continue to keep information secret and shield vendors from their mistakes. Security holes are not some kind of naturally-ocurring phenomena, nor are they something to hide from. They are the fault of vendors who do not invest the necessary effort to develop secure software. Publishing security holes publicly punishes these vendors, and gives them an incentive to improve their practices. Yes, there may be short-term pain as a result. But it's the only way to improve security in the long-term.
The IPv6 mess explains why a fundamental mistake on the part of the IPv6 designers has had giganitc effects on the cost of making an IPv6 Internet work in practice.
No, I'm not “done.” I still need to
or else IPv6 clients won't be able to connect to my server.
Besides, you missed Bernstein's point. If you're asking me to configure extra options, you've already lost. His solution to the address crunch is better that the current IPv6 specification because he has come up with a way to make the transition to 16-byte addresses happen automatically as part of regular software/hardware upgrades, with no extra configuration.
What are you trying to argue? That an automatic transition would be a bad thing? That an automatic transition has higher costs associated with it than a nonautomatic transition? I suggest you reread The IPv6 mess carefully.
How is it “win-win”? It costs money and effort for every administrator of a computer on a public IPv4 address to also acquire and enable a public IPv6 address. What exactly is their reward for spending time setting up useless IPv6 addresses their perfectly functional IPv4 machines?
Do you realize that all this added cost and complexity could have been avoided if the IPv6 designers had simply designed the IPv6 address space as an extension to the IPv4 address space, rather than an alternative to the IPv4 address space? Interoperability with IPv4 is the single largest issue preventing adoption of IPv6. Please see The IPv6 mess for much more detail.The showstopper with IPv6 is that it was not designed with a coherent transition plan in mind. Sure, once everyone is using IPv6 it should work fine, but making the switch from IPv4 to IPv6 has enormous costs associated with it.
The IPv6 mess by D. J. Bernstein has much more detail:
“The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
“In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other. The specifications could have defined a functionally equivalent public IPv6 address for each public IPv4 address, embedding the IPv4 address space into the IPv6 address space; but they didn't.
“This might sound like a very small mistake: after all, once IPv6 is working, we can move everything to IPv6, so who cares about IPv4? The problem is that this mistake has gigantic effects on the cost of making IPv6 work in the first place.
“In short, because of this mistake in the IPv6 design, making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address—and, for the same reasons, every administrator of a client on a public IPv4 address—has to go to extra effort to acquire and enable a public IPv6 address.
“Example of the difference: As of 2002.11, Google hasn't published IPv6 addresses for www.google.com. What exactly is Google's reward for spending time setting up useless IPv6 addresses for its perfectly functional IPv4 machines? In contrast, they've had IPv6 software for years.
“Under the current IPv6 specifications, to make the magic moment happen, not only do we have to convince a few thousand network programmers to do something with no immediate benefit, but we also have to convince millions of computer administrators to do something with no immediate benefit. This is an incredibly bad way to handle a transition.”
Ideally, I'd like to just use Unicode characters directly (not entities) for open and closed quotes, but I can't do this until I'm confident all clients are using Unicode (lots of people still use various legacy character sets ATM).
We need to separate the idea of name from the idea of location. Symbolic links let us do just that. You can install packages for your system in different locations depending on whether they are ``local'' or part of ``the system.'' All I'm saying is make sure they are accessible by the default names (using symlinks, if necessary).
Get a better font (i.e. one with slightly curvy quotes) and it will look better to you.
And I don't care if you find the layout Qt's authors have chosen annoying. You're free to install Qt wherever you like on your system and then deal with the consequences. But it's ridiculous to subject all Debian users to these hassles, especially since they could be avoided by adding one measly symlink to the Debian package.
If you want to install Qt to a non-standard location like /home/roystgnr/qt, that's your problem to make it work. High-quality software would make the prefix of a Qt dependency easily configurable, anyways.
You couldn't be more wrong when you say Debian ``compromises'' to achieve cross-platform compatibility. In fact, they want everyone to conform to their world view; this is an uphill battle and it will never work. Different upstream authors do things differently with their packages, and they're not all going to suddenly change because Debian and the FHS are yelling at them that they're packages are ``broken.'' They choose layouts that reduce the total effort required by them to support all platforms.
But if you're an upstream maintainer, Debian will change your package's interface downstream as they see fit and make it incompatible with your upstream version. Now all the programs which depend on your upstream interface will break on Debian. So Debian will fix those programs, too, if they happen to package them. But if they don't, your users are in for headaches.
Don't get me wrong, Debian is a fantastic operating system. But there would be so many fewer headaches for users if they attempted to ``play nice'' with other systems, rather than saying ``It's the Debian way or the high way!''
For instance, let's say I am installing version 1.0 of foo in prefix /package/misc/foo-1.0, and I want it to depend on the default installed version of bar, 0.5. I symlink
and I tell my binaries in foo-1.0 to always access bar.so by the absolute path(No need to consult /etc/ld.so.conf.)
Now, let's say I want to upgrade the default version of bar to 0.6, but I want foo to continue using the older version 0.5 because I know this combination is supported and known to be stable. I can simply change the symlinks to
No environment variables necessary. And you certainly don't need to ship private copy of libraries with each package.
Please tell me: How would you accomplish this scenario with an FHS-compliant system (upgrade a dependency for a given set of packages and not others)?
I knowOh yeah, I symlink all commands into /command, so I only have one entry in my $PATH :) (Of course, I have /usr/bin, /usr/sbin, /usr/local/bin, and /usr/local/sbin all symlinked to /command for compatibility.)
Thanks for your comment :)
Debian is indeed a superb distro and has some fantastic tools like apt-get. But if we want compatibility across different distributions, we're not going to achieve it by trying to force every package author to fit their package into a specific mold. Linux isn't like that; different parts are maintained by different people who have different styles. We're never going to get everyone to agree on RPM/Deb/FHS/LSB/etc. But if we let the upstream package maintainer decide on the names and locations (i.e. the interface) of his own package, and we stick with it downstream, we might be able to make it work. Note that Debian could add their own FHS-ized interface to a package if they want, they just have to commit to supporting the upstream interface as well.
No, the FHS specifically prevents cross-platform compatibility. For example, if a package is installed ``locally'' on one system it will have a different interface than if it installed as part of ``the system'' on another. For example, how do we find libssl.so on an FHS-compliant system? Is it /usr/lib/libssl.so or /usr/local/lib/libssl.so, or even /opt/openssl/lib/libssl.so? The FHS ensures we will never have a simple, consistent name, like we would have if the package author madated it to be /package/host/openssl.org/openssl/libssl.so.
Sorry, as many have pointed out, I am mistaken about apachectl; indeed, it works fine in Debian. But if you want to see what I mean, look at Qt: Follow the instructions for installing from source, and you will have everything accessible under /usr/local/qt; install the Debian packages, and you will see they changed the name to /usr/share/qt3.
Sorry, I am indeed mistaken about apachectl. But, as I explained in my other reply, please look at Qt and you will see an example of how different the Debianized package is.