Linked by Justin Piszcz on Mon 7th Jun 2004 05:37 UTC
General Development Example: You have the Linux 2.4.26 kernel source. Fact: You want to install the newest 2.4.xx kernel. Problem: You have GCC-3.4.0 installed. Solution: Temporarily install GCC-3.3.3. Here's where relink comes in!
Order by: Score:
bad name
by Richard S on Mon 7th Jun 2004 05:55 UTC

Hmz I thought this would allow me to actually re-link a program so that if a binary package was linked to libsomething-1.1.1.so that I could relink it to libsomething-1.1.2.so. I had to make a symlink for libpng once to make a binary-only package work with my version of libpng. It didn't pose a problem in this case. Although any real 'relink' tool should be able to find out if it'll work at relinking time.

Anyways, I think 'relink' is a very confusing name for a package management tool.

dpg vs rpm
by Anonymous on Mon 7th Jun 2004 06:31 UTC

Not another bad comparision between rpm and dpkg!

.deb is comparable to .rpm as it is the actual format of the package and how the database of files, package versions, etc... are saved on your system.

Above .deb or .rpm can sit apt or yum(only for rpm atm) which handles repository installation, and multipackage operations.

So why do people compare dpkg (a frontend to apt on debian) to rpm (a package format)? Its really not that hard to understand!

Newbie Friendly? Seriously!
by Azmeen Afandi on Mon 7th Jun 2004 06:45 UTC

Here's three tips regarding lib dependencies...
1) man ldd
2) cat /etc/ld.so.conf
3) man ldconfig

Explanation...
1) You can find out the lib dependencies of ANY program with this command (try ldd /bin/ls).
2) Believe it or not, you can actually add ANY additional lib locations in this file... after which you should run ldconfig.
3) The first three lines of this man page should be more than enough info.

And it really pisses me off for someone to say that these three steps are not "newbie friendly" enough. I mean how hard can this be? Isn't it roughly the same as how Windows programs scream about missing DLLs?

I really fail to see how installing relink can qualify to be more user-friendly than the steps I've mentioned.

I also have found no distribution that does what relink does by installing applications like the following example: /app/program-1.0/{bin,etc,man,lib,sbin}.

There is one, it is called "GoboLinux":
http://www.gobolinux.org/

Regards,
Offer

Very nice job, but...
by Anonymous on Mon 7th Jun 2004 07:26 UTC

I would mention the apps etc directory during upgrade. Some programs update their etc files inline and also removing the old etc dir loses the users configs ;)

Great job!

"So why do people compare dpkg (a frontend to apt on debian) to rpm (a package format)? Its really not that hard to understand!"

Apt is a frontend to dpkg, not the other way around. Check out the package description at http://packages.debian.org/unstable/base/apt and see for yourself.

Stow
by Seo Sanghyeon on Mon 7th Jun 2004 07:48 UTC

How is relink different from good ol' GNU stow? GNU stow have existed literally for ages, and I am happy with it when it comes to installation from source. What advantages does relink offer over stow?

@Azmeen Afandi
by Andrew D on Mon 7th Jun 2004 08:08 UTC

"And it really pisses me off for someone to say that these three steps are not "newbie friendly" enough. I mean how hard can this be? Isn't it roughly the same as how Windows programs scream about missing DLLs?"

If you feel that going and looking up man pages and then figuring out from that how to resolve dependancies is newbie friendly then it's obviously been a long time since you were a newbie. ;)

Oh and I've not for a long long long time had a DLL dependancy error while installing applications. While building them yes, installing them no, so comparing the regular issue of dependancy problems (affects the user) with DLL Hell (which is pretty much stuck at the developer level) is a bit naughty.

pkgviews
by Quentin Garnier on Mon 7th Jun 2004 08:49 UTC

relink is just like the "pkgviews" part of pkgsrc. You have a depot directory, usually /usr/pkg/packages, where software actually gets installed. Then you can manage views, which are really "link farms".

The default view is of course /usr/pkg, but you can have others, with a different set of packages installed.

Of course, with pkgsrc, you don't have to make all the downloading and compiling by yourself. You just do "make install".

@Andrew D
by Azmeen Afandi on Mon 7th Jun 2004 08:49 UTC

I've been using Slackware for about a year now, previously I've used Red Hat (hate it with a passion), Mandrake (the newbie-friendliest distro I've used), Lycoris (tried to hard to be like Windows).

I got my introduction to Linux via Red Hat 5. Dumped it ASAP (mostly due to winmodem issues, not to mention the tediousness of RPMs). Tried Mandrake 8.x (can't remember the point release), loved it... but I never actually learnt anything about Linux. Soon after, I gave Slackware a try, and I've learnt more about Linux during this past year as compared to 5+ years of using RH and Mandrake.

Anyway, what's wrong with referring to manuals when you have a problem with something? Not just talking about OSs here, but machinery, electrical equipment, and other hardware. The only (quite dumb) excuse that I can think of is that there's no possibility of people getting injured or dying if they used their OS improperly... hence, most won't bother.

So if newbies aren't using it, it does not mean that it's not user-friendly, please, give manuals a try... Sure, it might not be pretty, but most of the man pages are really straight to the point.

Regarding the DLL hell, sure, nowadays it's quite rare, unless of course the app you're trying to install insists on some strange MSVBVM30.DLL (I made this up purely for example, it most likely doesn't even exist) that was popular aeons ago. However, there's a new flavour of it right now... .NET Framework files (how big is this beast now, 10MBs?). And IIRC, whenever a new version of this runtime comes out, we do have to reinstall the WHOLE framework right, not just the particular updated part that we actually need.

I might be totally wrong though, please point out my mistakes if any... I'm really here to learn, and I'm more than willing to receive positive criticism.

silly example
by goo.. on Mon 7th Jun 2004 09:03 UTC

You have the Linux 2.4.26 kernel source. Fact: You want to install the newest 2.4.xx kernel. Problem: You have GCC-3.4.0 installed. Solution: Install gcc-3.3.3 and use gcc-config to switch between the two at will.

Gentoo already automates installs of different versions of sofware like different major versions of kernels, gcc, java environments, kde, gnome. For better relink PR, use better examples; problems only relink solves but no other package management tool.

Old idea
by Max Grabert on Mon 7th Jun 2004 09:15 UTC

Man, this is old news.

I've created a very similar tool over 6 years ago (called 'engage'), entirely written as a shell script (using find and sed). My later implentations inspired by the 'en(able)' scripts from Hubert Feyrer (of NetBSD fame), although before that I used a totally different design and implementation.

We both had a similar idea (independendly), so this concept of 'relink' is definitely not really a great unique invention, it is just something that you will come up yourself eventually. I'm sure others have created a app like 'relink' aswell, long time ago.

Back in the those days I even based my whole DIY-linux system on this principle (I still have it on installed on my old P133). When I was working at Sun Microsystems, I was approached whether they could use it, so I released it under GPL. (I actually don't know whether they really used it internally, since this was just before I left Sun).

To be honest, I haven't use it for ages. Mainly because I swiched to Debian long time ago, and there was no real need for me to use it anymore.

relink = epkg = engage = ...
by Jeremy on Mon 7th Jun 2004 09:23 UTC

I definitely vote for this way of organizing packages (all the way down to glibc). Can we have it in a major distribution please?

epkg does the trick for me (on an LFS system).

Graft
by Ade on Mon 7th Jun 2004 10:00 UTC

I use a Perl script called Graft (search Freshmeat) that does a similar job. This kind of software install scheme is outlined in a Sun paper called "The Art of Automounting" by Martien F. van Steenbergen and covered by Limoncelli & Hogan in Practice of System and Network Administration. It's definitely the way to go if you want to compile from source and still keep package files together. It also gives you a rollback path to previous versions.

Okay...
by Vladdy on Mon 7th Jun 2004 10:15 UTC

While I do kinda see how this is unique, multiple versions of packages live in Gentoo quite nicely...and the gcc-config program can handle multiple versions of gcc, if I'm not mistaken. The "USE" variable in gentoo lets you control features with relative ease, especially with handy ncurse-based frontends like ufed to make things more clear to the more casual user. Gentoo even handles a system with 2.4 and 2.6 kernels installed!

So how *exactly* is this dissimilar to Gentoo, with the exception of the path name changes...? I don't want a rant, just an answer.

RE: dpkg vs rpm
by Anonymous on Mon 7th Jun 2004 10:56 UTC

"So why do people compare dpkg (a frontend to apt on debian) to rpm (a package format)? Its really not that hard to understand!"

So what exactly is the binary used to install/upgrade/etc the .rpm's called? I always thought that it was rpm, but I am clearly mistaken.

Re: Azmeen Afandi
by jk on Mon 7th Jun 2004 11:48 UTC

About .NET versioning:

1. .NET supports side-by-side installation which means you can have any number of .NET runtimes installed and there's a future-compatible infrastructure to tell your application which runtime it should use.

2. .NET versioning model assumes (quite correctly) that applications work best when they run with the same libraries they were compiled with. If you test your application and you know it works with other runtime you can allow it by providing assembly redirection rules. Without your explicit permission it won't run (core assemblies are the exception, because .NET provides transparent redirection for them)

3. .NET supports loading assemblies side-by-side which means you can have two versions of a single component loaded into one process.

4. There've been two versions of .NET released so far. I don't see how this can be a DLL-hell.

Wow! I'm gonna stick to checkinstall
by Phil C on Mon 7th Jun 2004 11:52 UTC

Phew! I'll keep my slackware box on a checkinstall diet I think!

RE: dpkg vs rpm
by Anonymous on Mon 7th Jun 2004 14:32 UTC

Sorry, I made a typo. I havn't used debian in a while and I confused the tasksel package (or whatever it is called that provides easy access to apt, and dpkg comparable to the rpm layer. But dpkg does not do auto-dependency resolving just like rpm! dpkg and rpm are mostly the same. The reason debian dosn't have dependency issues is because of apt, which exsits for rpm too, in addition to yum.

So my original post (IP: ---.sothfd01.mi.comcast.net) is correct, I just confused one of the names. Sorry, I havn't used debian in a long while.

RE: dpkg vs rpm
by RaVen_ on Mon 7th Jun 2004 14:58 UTC

synaptic == synaptic (apt-get only)
aptitude == ...
apt-get == yum,apt-get
dpk == rpm

@jk
by Azmeen Afandi on Mon 7th Jun 2004 15:13 UTC

I'm not implying that requirements of the .NET Framework is just like DLL hell. The only similarity (that I can think of as an end user) is that the framework is required by apps that use it, of course.

However, the similarities with some core Linux libs, is that the size of each release is MASSIVE. That is what I meant by its "flavour". Let's say we're trying to run a simple 100k text editor, we're gonna need 10s of MBs worth of libs.

However, thanks for the explanation of the co-existing versions of the framework playing nice with each other. At least I learnt something new today ;)

Re: Anonymous (IP: 141.217.16.---)
by Syntaxis on Mon 7th Jun 2004 16:34 UTC

"The reason debian dosn't have dependency issues is because of apt, which exsits for rpm too, in addition to yum."

It's not as simple as that. Note for instance that rpm still has no support for "enhances", "suggests" or "recommends" relationships between packages, regardless of what frontend you're using.

so?
by hobgoblin on Mon 7th Jun 2004 18:45 UTC

i dont realy see the point of those 3 fields unless you have a popup or similar while installing saying "hey, this package recommends that you install those packages, suggests these and it just wnats you to know that it enhances that pacakge over there". as long as i tells you want packages it needs to have preinstalled for its content to work then it telling me all i need (except maybe a url or similar pointing me to where i can find them if they are not present)...

what is realy needed is for integration with kde/gnome so that you can "run" on a package file from there, have it passed to the pacakge manger for parseing and dependency resolving and if failure give the user a hint about go search say rpmfind or similar for the missing packages (or maybe this can be done by the manager. or the package can provide a default download site for its dependencys). this way the packages becoems as user friendly as the installer files in windows in my view.

glibc 2.9 glibc 3.2
by meirm on Mon 7th Jun 2004 19:05 UTC

Today I had a situation on Redhat Advance Server 3.
it comes with glibc 3.2. I need to run glibc 2.9, taking the rpms from AS 2 force me to do rpm -ivh --force -nodeps.
is relink the answer to this? is it ldconfig?

Re: so?
by Signals on Mon 7th Jun 2004 19:48 UTC

i dont realy see the point of those 3 fields unless you have a popup or similar while installing saying "hey, this package recommends that you install those packages, suggests these and it just wnats you to know that it enhances that pacakge over there". as long as i tells you want packages it needs to have preinstalled for its content to work then it telling me all i need (except maybe a url or similar pointing me to where i can find them if they are not present)...


Actually, apt does tell you those things when you are installing. It has been quite useful to me. When installing (oh, let's say) "emacs" it might tell you that "emacs-dev," "emacs-doc" or "emacs-elisp" is suggested. Emacs will still work without the suggested packages, so they aren't required. But it is nice to have the documentation or the development libraries sometimes. The "suggests" field tells me that there are other parts of the package that are not required, and gives me the names so I can install them if I wish.

-Signals

Yet another re-invention
by Peter Samuel on Tue 8th Jun 2004 14:10 UTC

While I admire your efforts at solving a problem that affected you, you may have benefitted from some more in depth research first. There are a number of packages that do the same or very similar things. In my research I encountered the following (roughly oldest package first)

depot
stow
graft (disclaimer, I am the author of graft)
encap
stowES
opt_depot
relink

None of these did what I wanted so I wrote graft (which predates relink by about 4 years so that's why I didn't consider relink when writing graft). From your usage examples I think graft still does a better job because it manages the package removal without really removing the package, only the symlinks.

For more details on my own research and graft, see

www.gormand.com.au/peters/tools/graft/graft.html

Relink - a package management tool
by haha on Wed 9th Jun 2004 01:35 UTC

I might say this would be a good package tool for LFS. And I can see a lot of room for improvements in order to make it ideal for LFS.

The concept is so simple, each app has its own install location, make a link somewhere so that other apps that use it can find them. By putting a central install location, accounting of apps is simple as doing an ls. Removing is also simple as deleting the directory. By using hard links, deleting the files will also delete the link. To make back-up, just copy the whole directory. To restore, copy back the directory and re-create the links.

That's it, this would be a good concept for LFS.
Regards.