On Sun, 2003-10-12 at 00:14, Sean Middleditch wrote:
LSB is just this, and many distros are LSB compliant these days.
Yeah, but LSB is really really LCD. No GUI libs (yet) for instance.
This sounds like it needs to be fixed; i.e., an easy way to disable
that. I know apps linked against older libcs work on RH9 (usually, the
occasional odd app fails, which is quite unfortunate).
That's what apbuild/apgcc do - ideally of course upgrading glibc would
be just like any other library but for some reason it isn't, so we have
to wind back the clock a little bit. Fortunately thread-local locales is
a features mostly useful for servers I think, so client side apps don't
need to worry about losing it.
That would be interesting. The problem is, then, every single app
that
possibly exists in the application/dependency archive would be in the
menues. Ick.
No, only stuff the user had installed.
While I understand the use cases, as I've said on the autopackage
lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).
Please do so. I'm not sold that we need any specific app management
program - it's the sort of thing users just never think about (much like
uninstalling stuff they no longer use).
Which isn't really possible. The best you could do is inform the
user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.
The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.
Maybe.... still, it's been done in Java/C# for ages, despite the
difficulties. It seems unintuitive that it's possible with objects but
not packages.
Evangelism on the importance of proper development practices could
be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)
Yeah, I want to do this too at some point, probably as part of the
packagers/developers guide we're writing for AP. There is a good paper
by Ulrich Drepper on writing DSOs, but it's basically impossible to find
unless somebody shows you. Other bad techniques are compile time
options, non-relocatability and so on. Developer education is definately
a part of the solution.
thanks -mike