Why Aren't ./configure Parameters Preserved?

dhammabum asks: "I've just installed a machine with a copy of Red Hat 6.2. I thought I would use the squid RPM that comes with the distribution to save time, etc. All went well until it tried to set up delay pools as this configure option had not been set in the RPM. So I then had to stuff around for quite some time working out how the RPM differed from the distribution. It even turned out the install options they used were broken -- they had to link a directory to get it to work! This begs the question -- why not have the configure options included with the RPM, say in /usr/doc, so that when one has to change something you simply add or subtract whatever you need to change, rebuild the package and reinstall?" I've always wondered why source-handling package managers like dpkg ^[?] and RPM ^[?] haven't implemented such schemes, allowing users to pass flags to configure and preserving them for the next time the package needs to be built. Does anyone have any ideas as to how such a system would best be created? Are there package managers that already do such things?

Many times, when I build packages from source, they are done so outside of the package management system because it's easier to do "./configure options; make; make install" than it is to figure out the myriad of parameters available to RPM(8) or dpkg-buildpackage(1) to properly do what I want. This also means that said packages are most often installed in /usr/local and must then be uninstalled by hand.

It would be nice (and essential for Linux novices) if packages could be built from source, and customized, but still remain under the umbrella of the distribution's package manager with the customizations saved for later use. Are there any efforts to bring this kind of functionality to the current distributions?

Re:Story posting problems?

[penguinboy]

It's harder than it sounds.. in order to register kernel 2.2.16, you'd have to actually install every file that came with the RPM. It's possible that programs depending on the 2.2.16 RPM need something besides just the kernel image. Now, I suppose kernels don't make a very good example, because they're fairly simple in terms of files provided (I think..).

The other thing is, by simply registering an RPM, the RPM database won't have the list of files provided by the real RPM. Then, it won't be able to inform you of conflicts in the future.

It looks to me like this would end up making quite a mess. A better way to deal with the problem of --nodeps ignoring stuff you haven't noticed would be to make rpm -[iU] always print a full list of unfulfilled dependencies (if it doesn't already and simply prints the first one).

Just my $0.02

Re:Story posting problems?

[cheeserd00d]

This story post was a pure 'Ask Slashdot' only post. That means it is put in the 'Ask Slashdot' section but not featured on the main page. Certain ones (ones probably seen as more important in Cliff's eyes) are featured on the main slashdot page. If you want to see all of the 'Ask Slashdot's, including the ones not posted to the main page, then go to your user preferences -> customize homepage -> and check 'Ask Slashdot' for one of your slashboxes or just go to http://slashdot.org/index.pl?section=askslashdot

Re:Story posting problems?

[sparkz]

Looks like it ... I'd be kind of interested in this discussion, tho.

All I'd like (and I guess it'd be easy to write, but I'm not a C programmer), is a way to register with the RPM database that a certain package is installed, eg:
I install kernel-2.2.14.rpm
I install /usr/src/linux and compile 2.2.16.
I register with the RPM database that kernel-2.2.16.rpm is now installed
I can then install packages which depend on 2.2.16 without having to do the --nodeps option which would ignore other deps I'd not thought of

So, any offers to write that? Just add and remove the entry from the database...

Re:Story posting problems?

[rifter]

I think some tools to edit and otherwise interface with the rpm database directly are in order. Especially since they would help deal with rpm database corruption (which is annoying).

# rpm -U niftypackage-1.2.3.rpm

niftypackage-1.2.3 needs libpackage-3.2.1

# rpm -U libpackage-3.2.1.rpm

libpackage-3.2.1 is already installed.

# rpm -q libpackage

#

# rpm -e libpackage

libpackage is not installed.

# rpm -U libpackage-3.2.1.rpm

libpackage-3.2.1 is already installed.

Darn it!

As for your particular problem, currently one could create one's own rpm and install it, but I understand this is not what you want to do in this case. I think it would be nice if there was a way for rpm or whatever to check the system and find the files installed, then update the database on that basis. That way if the database itself gets hosed, you could always build another one. As far as I understand rebuilddb does not do that, but instead does a sort of sanity or consistency check, but I could be wrong.

hmm.

[7-Vodka]

well, I think that it may be a good idea to allow users to play with the flags in packages. However this would have to be done in a way that also simplifies the procedure no? Why even get an RPM at all if you need to go read all the readmes and mess with the flags the same way you would do with a tarball? qu3?

SRPMS

[embobo]

I recommend getting the source rpms. Then you find out exactly how it was built and installed. You can also make some changes and remake the SRPM.

Re:Story posting problems?

[ywwg]

This already exists!

try creating a file called /etc/rpmrc. Add the following line:
provides:kernel-2.2.14-5.0

et voila, rpm now thinks you have that package, even if you don't. I have xfree 4.0.1, and I created the following rpmrc:

provides:libICE.so.6
provides:libSM.so.6
provides:libX11.so.6
provides:libXext.so.6
provides:libXi.so.6
provides:libXmu.so.6
provides:libXt.so.6

Rpm thinks I have X-free rpms installed, so I can install any rpm without having to do a --nodeps.