Lately, RPM has been my main/favorite package manager, even tho I have to use Sun pkgadd on those platforms. Below... (not restricted to RPM, but relating to distributed package managers in general viz. NFS mounts for example) -----Original message----- From: Jeff Johnson n3npq.jbj@xxxxxxxxx Date: Tue, 29 Aug 2006 15:39:43 -0230 To: RPM Package Manager rpm-list@xxxxxxxxxx Subject: Re: split database > On Aug 29, 2006, at 1:59 PM, Steve Friedman wrote: > > > > I've tried searching the archives, to no avail, as I suspect that > > the answer is no. > > > > I have a device where a small fraction of the software is internal > > to the device and the majority of the software resides on removable > > media (a compact flash card). I am also interested in that kind of functionality in package managers. For me, this became a concern when trying to manage installed software on Sun workstations, where some/much of the software was shared via NFS from server(s). I would have liked to setup the same kind of thing for various Linux machines. This could keep local disk very small, without going totally diskless (gets complicated and really messy, and usually restricts to "standard configurations"?). Maybe I did not try hard enough, but I couldn't find any package managers that could handle that kind of distributed file system. IMO, it would be ideal to have a package manager that can do installs on a "master machine" (or server?) with write priviledges, but can also be used on client/slave machines to report on what software is available, and check on completeness and dependencies, etc. I still don't know of any, but I have not worked with Tivoli or anything like that. Can they do it? BTW, it has turned out that a lot of software really expects to run on a local disk that is totally "owned", and many things get really confused by distributed pieces (might not be available, if network problem) or read-only on some NFS mounts. I guess the FHS as a standard is not that rigorously applied? It does (sort of) recommend what parts of the file system could/should be read-only, and therefore could be served up by a read-only shared NFS mount. I've had trouble with this, viz. ruggedness. For simplicity and sanity, I guess everyone just slams big disks in everywhere and loads everything local? I guess that is most robust, since one is then invulnerable to network problems. OTOH, it makes for more complicated updates and consistency. > > Is it possible to configure rpm (and/or use multiple dbpath > > arguments), so that each media would contain a database only of the > > packages installed on that media and rpm would read both databases > > before returning an answer (and, more difficultly, determining > > which database to write on an update)? > > Its certainly possible to use multiple databases and you're not the > first to request the functionality. > > The issue is deciding which of several databases becomes the rpmdb > used for installing. A loop over multiple RDONLY databases with > the current rpmdb iterator is rather easy. Again, ideally (for my situations) it would be nice if the package manager can figure it out, or be configured. On a "master" machine where one can install shared software back onto the NFS servers to be seen by other "slave" client machines, it would be nice if the package manager can do the installs and updates to the appropriate database. If stuff is on an NFS share, then it would be convenient if the package manager database fragment could be on that device also. I suppose there would have to be internal versioning info, so that someone does not accidentally misconnect different versions of the package manager and/or package loads that belong to different distro/os releases. That gets very hairy indeed. In my real world, I have different versions of different distro/os on shared NFS file systems. Life is heterogeneous! > FWIW, the first step towards permitting multiple databases within rpm > was adding the rpmdb-redhat package to display suggestions and > automagically populate a transaction with additional packages > when using --aid. > > All this work was shelved when Fedora Core decided not to distribute > a rpmdb-fedora package because its kinda hard to read a database > that isn't there (my devel system has been Fedora Core). My trajectory through different Linux distros has been: Slackware, RedHat, Mandrake, SuSE. Lately, I have thought of moving again, since the latest SuSE/Novell evolution to a money extraction scheme (maintenance, yearly license, subscription, whatever) is not that comfortable to me. I was buying approximate yearly updates at $50. Not sure I get anything I need for $350 server license, even though I run several of my Linux machines as servers. If I'm going to spend $350/year on server, might as well go Solaris. BTW, it bugs me that I cannot (as a check) cleanly rebuild a distro. I guess that is a very difficult configuration management problem: to make sure that all the .src.rpm that are out there for a distro are consistent. IMO one should always be able to rebuild from .src.rpm otherwise one can never be sure that one actually has everything (consistent). How do you guys like Fedora? Is it now the best free/open distro? I don't mind paying for value, but don't like strong arm. > > As it stands now, we are looking at gyrations with multiple > > invocations. > > > > If the number of packages on the smaller media-set is like 10-20, you > might > be able to do queries with a wrapper, invoking rpm twice, each with a > different --dbpath. Presumably that's what you are already doing. > > Another method would be to re-import the packages from one media-set > into the other using --justdb. > > 73 de Jeff > > _______________________________________________ > Rpm-list mailing list > Rpm-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/rpm-list p.s. I think what I would ideally like is some kind of meta-level package manager that can talk to other package managers, and build a composite picture of what is actually installed on (or "visible" from) a particular machine. ISTR there was some lisp configuration manager that was aiming at such functionality? Does anyone know where/how that fits? How do other people at other sites manage their distributed heterogenous software on different platforms? At one point, I tried using pkgadd for Solaris packages, and RPM for my own (and open source) software on my Solaris machines. That was a fight, and it seemed that there were many problems with different versions of shared components. -- Juhan Leemet Logicognosis, Inc. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
