On Monday 17 October 2005 14:06, Les Mikesell wrote: > On Mon, 2005-10-17 at 12:40, Lamar Owen wrote: > > > What is it that could be explained that couldn't be scripted? > > More than you might realize given the constraints of the RPM system. > Yes, the decision to disallow user interaction during RPM installs > is probably the worst thing ever to happen to Linux. There are > things where defaults aren't ever going to be right. But, you can > always work around it by making the interactive part happen later. Unless the interactive part is asking you to dump a database for which you no longer have a backend capable of reading the data. I tried to work around that, but it was not a robust solution. Unfortunately, there have been version transitions in PostgreSQL where the new version of pg_dump was needed to back up the older database, meaning you had one version of postgresql (for the clients) and another version of postgresql-server (for the backend). Doing this during an OS upgrade is impossible thanks to the environment under which an OS upgrade is performed. The workaround saved off a copy of the binaries necessary to do the dump; however, the RPM dependencies for those executables were not guaranteed to stick around, and it was horribly fragile, depending upon version delta. > > And the script interpreter, regardless of language, takes things far more > > literally than even the rankest newbie following an explanation. > But it will complain a lot less... Well, that depends upon language, and how pedantic you have set warning levels... :-) At least the complaints will be readable, and somewhat meaningful. > Yes, this is where the 'do the interactive portion later' hits a snag. > There are things that have to be done before you blow away the code > needed to do the first steps. Yes, precisely the problem. > > It is far easier to explain "dump, upgrade, initdb, restore" than to > > write a script to do some really hairy data manipulation that can: > > The script only has to be done once by a person that understands the > issues. The explanation has to be done once per user - and they are > likely to get it wrong. Assuming the issues don't change version to version. Guess what; the issues do change between versions. Sometimes they change dramatically, as in the actual binary format. Sometimes the whole tree changes with a complete makeover of file names and such. Sometimes it's small metadata changes. The problem becomes one of manpower. There is only one person I believe to be capable of capable of writing such a migration tool, and that is Tom Lane. And he is swamped. > > Or to put it very bluntly: being newbie-friendly is hard work for a > > developer, but even harder work for support staff or mailing list > > participants. > The more that is done right on the development/packager/installer side > the less support is needed. Agreed in principle. But in the case of the OP, the issue became one of 'why can't I use $third-party-package' anyway? And this is, IMO, one of the greatest weaknesses (yet at the same time the greatest strength) of open source development, and that is the wide disparity of the class of developers and the decentralized nature of development. Take Cinelerra, for instance. For a while that beast shipped its own base libraries and built them along with the application, because the developer needed very particular versions of everything. On the other hand, take CrossOver Office, which leverages the Loki Installer very nicely. But even then the support issues are thick. > If you have to understand anything about a package manager, then it > isn't doing it's job - unless you mean building the packages. Well, the Red Hat-ish distributions have their own quirks that aren't related to choice of package manager. Having cross-packaged PostgreSQL for as varied a lot as SuSE, Caldera OpenServer (when that was the name), Red Hat, Mandrake, and TurboLinux, I can say from experience that RPM isn't the problem when it comes to distribution portability. Each one has unique quirks, version combinations, and macro sets. (Yes, spoken from a packager point of view). This is simultaneously a strength and a weakness, as already mentioned. But one of the reasons I use CentOS is at least the potential capability of running the same distribution on every machine I have, including the SPARC's and the Alpha. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu