Operating Systems > Linux and UNIX
Ubuntu: The Verdict
ksym:
JUST REMEMBER:
I do NOT want any non-base-system spesific into my /usr
-directory, or I will sue your ass to the highest court ...
if possible ;)
And there must be a way to determine if I want ONLY the
runtime libraries/binaries installed, so that the
development includes, m4-macros, pkgconfig entries are
installed ONLY if I want to!
Make the system behave so, that these software are installed
under /opt/unipkg/ -hierarchy.
For easy maintenance, each package should be installed
in it's own, isolated directory, eg. /opt/unipkg/ .
Each app can then be launched either separately from it's
directory, or symlinks made to it's binaries. These symlinks
would be stored to, for example, /usr/local/bin.
A version control mechanism MUST be provided. I want to
be able to decide EXACTLY what version of development
headers I want to use for my project.
This could be done quite simply by installing the packages'
binary images into /opt/unipkg//,
and install includes/pkgconfig entries/m4-macros into
/opt/unipkg// .
The would be the Real version of the package,
eg. 1.2, and the would be the version
of a compatible interface, like 1. Then we could determine,
that the development files in /opt/unipkg//1
are compatible with the runtime binaries in directories
/opt/unipkg//1.x ...
And if the package uses some other versioning scheme, there
should be some other mechanisms to resolve compatibilities ...
but deterministic versioning support is a must!
A smart ldconfig manager is also needed, so that each library
is installed in it's own directory, and the directory entry is
then added to /var/unipkg/ldd/ld.so.conf, parsed with
ldconfig to a temporary /var/unipkg/ldd/ld.so.cache,
which is used when launching Unipkg-spesific applications.
When installing a package with some runtime libraries,
the sequence would go:
--- Code: ---
check if the packages /opt/unipkg///lib -path is in the file /var/unipkg/ld.so.conf, and if not, add it there
ldconfig -f /var/unipkg/ldd/ld.so.conf -C/var/unipkg/ldd/ld.so.cache
--- End code ---
To launch a unipkg app, the command sequence could be
something like this:
--- Code: ---ldconfig -N -X -f /var/unipkg/ldd/ld.so.conf -C/var/unipkg/ldd/ld.so.cache && /opt/unipkg/MyApp/bin/myapp
--- End code ---
Well, this is my idea on how package management SHOULD
be done. I really hate the way modern distros spread their
libraries/binaries/whatever under /usr -hierarchy.
It is totally chaotic ... it just sucks!
Anyways, I really hate these defects in the current
GNU/Linux distributions:
- no support for EXACT development component versioning,
eg. I have no EASY way to determince exactly which interface
version of a library I wish to use during program linking
- no way to dynamically relocate package, since all
software is statically prefixed to /usr ... this is
a fucking retarded way to install software. What is
so deadly wrong in installing each software into it's
own, isolated directory structure?
- ldconfig has many options, which allow dynamic relocation
of libraries (eg. each lib CAN be in it's own directory),
but these options are not used ... pff
I started ranting again, but I do it for the sake of the
whole OSS scene. They do not know how wrong they do things ...
piratePenguin:
--- Quote from: ksym ---I started ranting again, but I do it for the sake of the
whole OSS scene. They do not know how wrong they do things ...
--- End quote ---
All that stuff you describe could be used in a seperate package manager, like RPM or whatever. Someone can package the source ('universal') packages into and RPM and distribute that. And if RPM doesn't suffice, they could use/invent their own package manager.
I installed FreeBSD yesterday (again), it's ports collection is very nice, and to my surprise, it *does* used patches to make the changes to the original code! And then after that, all it is is 'make && make install', and the package is compiled and installed. Bloodey brilliant.
So yea, nothing innovative here.
piratePenguin:
On the topic of package management, this project seems quite interesting.
worker201:
--- Quote from: piratePenguin ---On the topic of package management, this project seems quite interesting.
--- End quote ---
If grandma can't install an rpm package, why do we want to make it so she can install from source?
I like Linux like it is, really, and I don't want anything to be dumbed down.
piratePenguin:
--- Quote from: worker201 ---If grandma can't install an rpm package, why do we want to make it so she can install from source?
--- End quote ---
Erm, I dunno about yer grandma but most users do know how to install RPMs on an RPM based distro (e.g. Mandriva). There's graphical frontends all that now.
--- Quote from: worker201 ---I like Linux like it is, really, and I don't want anything to be dumbed down.
--- End quote ---
I like the way it works, to an extent. If I had the chance, I'd make some changes. But still, it's working alright.
What do you mean by "dumbed down" though?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version