[DB] package with not pure debian software [was: Selecting preferred database]
Steve Langasek :
>On Mon, Jun 10, 2002 at 03:47:10PM +1000, Matthew Palmer wrote:
>
>
>>On Mon, 10 Jun 2002, Giuseppe Sacco wrote:
>>
>>
>
>
>
>>>Actually when installing an application that for instance uses a DBI or
>>>PHPlib interface you have to scan for every database engine installed and
>>>then ask the user to select one of them. After choosing the engine you
>>>have to select a database instance name and some users/passwords.
>>>
>>>
>
>
>
>>>When you upgrade a database engine you would probably need to stop
>>>applications that uses the engine and then restart them.
>>>
>>>
>
>
>
>>>When you want to uninstall applications you could remove the associated
>>>database instance. When you remove database engine you could ask the
>>>user to migrate to a different engine.
>>>
>>>
>
>
>
>>>I would like to have some infrastructure to support all these operations
>>>in a standard way.
>>>
>>>
>
>
>
>>It's not absoloutely standardised, nor perfect most likely, but I seem to
>>recall an example in some Debconf documentation to do an almost identical
>>thing. There is also a system to do precisely that in the X servers to
>>select which X server to use as the default. It lists the X servers
>>currently installed and asks which one you want to use. I'd suggest going
>>to the debconf docs and, more importantly, the X server config scripts.
>>Write a generalised interface to this sort of hooplah (assuming the debconf
>>interface is too clunky - I don't think it is) and get everyone - databases,
>>Java programs (ugh), and X server - to use it, and the world will be a
>>better place.
>>
>>
>
>My principal objection to this talk of automatically scanning for
>available database engines is that it ignores the fact that SQL servers
>are *servers*, that is, there's a client-server architecture here which
>doesn't require the database engine to be installed on the local host.
>In fact, at work we have centralized database servers that we connect to
>from a number of other machines, so any configuration tool that lets me
>choose from a list of locally-installed database engines is worse than
>useless to me.
>
>Rescanning when the database *driver* package is removed might be
>acceptable, though. Otherwise, generalized, reusable debconf code for
>handling complex administration tasks would be a good thing, IMHO (so
>long as it's written right :).
>
>Steve Langasek
>postmodern programmer
>
>
Along the same line of my last question, if the package is not going to
work with a standalone pure debian box, should the software being packaged?
And where should I read about this topic? ( not about license but the
direction
or rule of what to package and what not )
Alex
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: