Vincent,

I *do* like the idea of auto-update. It is quite a nice option when you have
lots of similar servers in a cluster.

I toyed with the idea for a real long time. I am managing an ISP sysadmin
department and a 'local update server' would save us *lots* of work. However
as it stands, I am _not_ ready do deploy this feature, as I consider it
unsafe.

There is not way you can convince me that auto-update is safe as long as
configuration file are generated on the postinstall section.

For example: we _updated_ an RPM few week ago (I am not sure if it was one
of your or not. In doubt let assume it was not), as a consequence we nearly
lost our data as the RPM decided to clean the configuration file and
*directories*. This is clearly a RPM programming issue, but like stack
overflow, as long as it can be done it will happen !.

In order for me to change my mind, RPM would need to be splited in smaller
part, the less you touch things the more luck you have to keep a working
system.

RPM are already splited with the 'devel' addition. this modularisation
*need* to be extended.
(And YES I have an idea of the work,pain and complexity - ie customer
problems - related to this idea).

In _my_ ideal world, all installed application are composed of 4 RPMs:
- Libraries (shared component which can be used by other Application RPM)
- Application (binaries, what you expect to be installed to run the stuff)
- Configuration (which should be a requirement by Application)
- Development (devel .. nothing change)

Those 4 parts are not usefull all the time but it would work nicely.

It have advantages for OEM as well. It simplify the creation of custom CDs,
as all specific changes will not have to be located in one BIG installer
postinstall section.

As well, it would simplify update of custom RPM based on Mandrake (It is a
time consuming task to follow your RPM development to keep our up-to-date
our parralel set).

Flame expected and welcome :-)

Thomas

For help, email discuss-helpmandrakesecure.net; to unsubscribe send a
message to discuss-unsubscribemandrakesecure.net. To visit MandrakeSecure,
go to http://www.mandrakesecure.net/.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]