On Tue, Oct 24, 2000 at 11:12:06AM -0500, Jeffrey Watts wrote: : Seems to me we've had a consensus for a long time. It's always been RPM. : The only reason that the issue ever comes up is that someone new to the : mailing lists jumps in and starts dragging the issue up again.
If I may, the problem may be a bit more in defining things a bit better. The way that I see it (and I have looked through the archives, and attempted to "get up to speed" is that the objectives are not that clear. In defining a package type it seems to be you are actually doing serveral things. o pre-install checks. Check dependancy, etc. o software install. Put files where they need to be. o post install configuration. Update config files Run cleans up Update system letting it know that you just did. (Yes, I'm living quite a bit out, but hopefully my idea is there) What I see, to accomplish the first part of dependancy, the effort to define a package is a bit of overkill, when really it is a way to define what is installed on the system (Which in part effects that last part). Would it possible to say that the package database is the rpmdb? This would mean that any installation package system would standardize on the rpmdb but would be free to complete the non-db related package managment as it see fit? I'll admit, I have personally looked into it, but I don't see any major problems if say, and .tgz or .deb package used the rpmdb format (as well as it own). Yes, but be a bit of overkill, but it would accomplish the goal, wouldn't it? You would have a central area for installed software information, and could very easily standardize on the format the data is stored. I hadn't seen this take in the previous discussion. It is possible that I missed it though. : Note that Nicholas Petreley, when he started the current thread, : acknowledged that we have agreed on RPM -- he just was wondering if there : might be a better way, something that no package manager has done before. : Others pointed out that changing our package standard isn't really : productive at this point. Note that none of this implies that we haven't : decided on something. Here is my problem, I don't think package management is what we want, as much as package INFORMATION. Am I thinking wrong on this? : Put it this way: RPM's the starting quarterback here. The LSB isn't going : to consider some new proposal unless it's completely fleshed out and : addresses ALL of the issues involved (which are considerable). Note that : packaging systems like RPM and DEB didn't get coded overnight. I agree here, the better way might be out there, and it is not available. My problem is that standard might be trying to define too much? All package management systems have good and bad points, but they have one BASIC purpose, to store information about the files on the system and get get the files installed. Anything else, as I see it, is extentions of that. : Also, we've all pretty much decided that it's not worth our time to pursue : an alternative solution, as RPM does 99% of what we want it to. So that : pretty much means that if anyone wants to see this done, they have to do : it themselves. : : Remember, the LSB isn't here to pursue technical perfection. It's a : _practical_ standard. RPM is the path of least resistance. Folks can : argue its technical merits until they're blue in the face, but the fact is : that RPM has the largest installed base, it does what we want it to do, : and there are tools that allow us to use RPM on non-RPM based systems. : This is a fait accompli. I agree, it is there lets use it. Or at least parts of it. Manipulating the rpmdb shouldn't be that hard, so making LSB "ready" package management system that modifies a standard database could achieve the goal of standard package management without limiting the software used to do it. Mat <[EMAIL PROTECTED]> Blinky Light Sync-er.
