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
