Your message dated Tue, 6 Jan 2009 16:51:00 +0200
with message-id <[email protected]>
and subject line Re: Bug#218145: extend dpkg, should be able to switch package
on and off
has caused the Debian Bug report #218145,
regarding extend dpkg, should be able to switch package on and off
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
218145: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218145
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Subject: extend dpkg, should be able to switch package on and off
Package: dpkg
Version: 1.10.18
Severity: wishlist
if you are in a high-availability-environment or clustered environment,
you should be able to distribute and configure a package, and then switch
it on. switch back to original in a very short time should also be possible
(seconds?). and the
important thing is: the time used should not depend on the size of a pkg.
alternatives are not sufficient for this, and also install and remove pkg is
not sufficient for
this. you have different levels of "doing - undoing":
- new software or old software, including configuration.
current linux level (dpkg e.g.).
- new software and old software
this suggestion. trivial.
switch pkg off, or switch
another pkg version on.
- new configuration and old configuration
switch back and forth is trivial.
somehow the old config must be saved on switch
(or before, changetrack extension?)
- new data and old data
switch back and forth is not trivial.
new programs could write damaged data
and you have to have a procedure
for handling this, like:
switch back, and redo what you did.
you would need a "changetrack for data"
- new data format and old data format
switch back and forth is not trivial.
on install you could copy original data
to new format.
you would need a "changetrack for data
in different formats".
(trivial does not mean it is 5 min to implement, but there should be no problem
in implementing
it)
-s.
--------------------------------------------------
there was a wish 178382 already, but the comments made me write this one:
>Previously Ben Collins wrote:
>> You could do this with alternatives, like what is already done for
major
>> versions of other programs (like python 1.5/2.0/2.1/2.2).
>
>You can also do this by simply installing and removing the debs.
>
>Wichert.
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
--- End Message ---
--- Begin Message ---
Hi!
On Wed, 2003-10-29 at 02:04:58 -0800, solo turn wrote:
> Package: dpkg
> Version: 1.10.18
> Severity: wishlist
>
> if you are in a high-availability-environment or clustered environment,
> you should be able to distribute and configure a package, and then switch
> it on. switch back to original in a very short time should also be
> possible (seconds?). and the important thing is: the time used should not
> depend on the size of a pkg.
I don't really understand what you mean with switching a package "on",
but I'll try to guess.
> alternatives are not sufficient for this, and also install and remove pkg
> is not sufficient for this. you have different levels of "doing - undoing":
> - new software or old software, including configuration.
> current linux level (dpkg e.g.).
> - new software and old software
> this suggestion. trivial.
> switch pkg off, or switch
> another pkg version on.
The data itself would have to be on-disk even if the packages is "off"
but that would bring the file conflicts problem anyway. To solve that
those packages would have to be staged somewhere else, which implies
some sort of stow structure.
But this can already be done with dpkg currently, and one can use what
Ben and Wichert described, using co-installable packages and switching
among versions using alternatives for example. That's just a matter of
packaging policy.
> - new configuration and old configuration
> switch back and forth is trivial.
> somehow the old config must be saved on switch
> (or before, changetrack extension?)
> - new data and old data
> switch back and forth is not trivial.
> new programs could write damaged data
> and you have to have a procedure
> for handling this, like:
> switch back, and redo what you did.
> you would need a "changetrack for data"
> - new data format and old data format
> switch back and forth is not trivial.
> on install you could copy original data
> to new format.
> you would need a "changetrack for data
> in different formats".
In that case you would still have the problem of the configuration
migration (new formats etc) and/or the data (like a database). And
that would have to take into account data transaction on the old
database while you are converting and switching to the new database.
Starting and stopping the daemons, etc. The case of rollback has been
requested in another bug so I'll ignore this here.
And then this has nothing to do with dpkg itself, that's a packaging
policy issue and would get fixed by implementation on each package.
So I'll just close this bug report.
> --------------------------------------------------
> there was a wish 178382 already, but the comments made me write this one:
> > Previously Ben Collins wrote:
> > > You could do this with alternatives, like what is already done for
> > > major versions of other programs (like python 1.5/2.0/2.1/2.2).
> >
> > You can also do this by simply installing and removing the debs.
> >
> > Wichert.
regards,
guillem
--- End Message ---
