On Thu, Oct 15, 2009 at 10:51:20 -0500,
chasd wrote:
>
> Bruno Wolff III wrote:
>
> >Postgres isn't even updatable. You need to do dumps before doing
> >the upgrade.
>
> OK, maybe that isn't a good example then.
>
> However, using your comment, and turning my idea around, if
> PostgreSQL isn
Bruno Wolff III wrote:
Postgres isn't even updatable. You need to do dumps before doing
the upgrade.
OK, maybe that isn't a good example then.
However, using your comment, and turning my idea around, if
PostgreSQL isn't upgradable, according to my idea it should be
excluded by default i
Charles Dostale wrote:
MySQL and PostgreSQL come to mind.
/etc/yum.conf might have " nodowngrade=mysql-server postgresql-
server " in the default file.
Seth Vidal wrote:
I have no idea what that would do? just tell the user "tough noogies"?
" can't be downgraded because of file format ch
On Wed, Oct 14, 2009 at 13:55:13 -0500,
chasd wrote:
>
> MySQL and PostgreSQL come to mind.
Postgres isn't even updatable. You need to do dumps before doing the upgrade.
So downgrades aren't too much worse than upgrades. (Though the new dumps
might use new features that will need to get modifi
On Wed, 14 Oct 2009, chasd wrote:
Seth Vidal wrote:
Seriously:
yum downgrade
and in F12 - try out things like the history undo options.
there are lots of potential nasty situations that can happen but I think
the general consensus was 'screw it, let the user sort it out if it breaks,
w
Seth Vidal wrote:
Seriously:
yum downgrade
and in F12 - try out things like the history undo options.
there are lots of potential nasty situations that can happen but I
think the general consensus was 'screw it, let the user sort it out
if it breaks, which it often does not'
generally,
Le Mer 14 octobre 2009 19:11, Jud Craft a écrit :
> So if my "LVM snapshot and revert entire Fedora installed" idea is
> dismissed as "still not perfect", why is "just revert one package"
> pushed as a legitimate alternative?
Revert one package won't eat the data created while you used the new
On Wed, 14 Oct 2009, Jud Craft wrote:
On Wed, Oct 14, 2009 at 1:13 PM, Seth Vidal wrote:
There's no perfect.
we're just going for 'good enough', really.
Ah, so package-rollback is shipped as the "halfway-effective crutch,
but it's so easy to implement we might as well offer it anyway"
solu
On Wed, Oct 14, 2009 at 1:13 PM, Seth Vidal wrote:
> There's no perfect.
>
> we're just going for 'good enough', really.
Ah, so package-rollback is shipped as the "halfway-effective crutch,
but it's so easy to implement we might as well offer it anyway"
solution.
Or, the excellent implementation
On Wed, 14 Oct 2009, Jesse Keating wrote:
On Wed, 2009-10-14 at 10:49 -0500, Mike McGrath wrote:
have no way to fix a mistake
That is complete bullshit. You have many ways to fix mistakes. Newer
builds with patches, reverted code with epoch, newer upstream release to
fix the mistake upstr
On Wed, 14 Oct 2009, Jud Craft wrote:
On Wed, Oct 14, 2009 at 1:08 PM, Jesse Keating wrote:
Newer builds with patches, reverted code with epoch, newer upstream release to
fix the mistake upstream, etc.. To say that there is no way to fix a
mistake is insulting.
I'd like to logic-link here
On Wed, Oct 14, 2009 at 1:11 PM, Jud Craft wrote:
> They both suffer from the same problem -- new packages may cause
> changes in data that are not reversibly compatible with the old
> package, and mere package rollback is not useful.
>
Of course, I imagine that any rollback system that doesn't in
On Wed, Oct 14, 2009 at 1:08 PM, Jesse Keating wrote:
> Newer builds with patches, reverted code with epoch, newer upstream release to
> fix the mistake upstream, etc.. To say that there is no way to fix a
> mistake is insulting.
I'd like to logic-link here with the following...
On Wed, Oct 14,
On Wed, 2009-10-14 at 10:49 -0500, Mike McGrath wrote:
> have no way to fix a mistake
That is complete bullshit. You have many ways to fix mistakes. Newer
builds with patches, reverted code with epoch, newer upstream release to
fix the mistake upstream, etc.. To say that there is no way to fix
On Wed, 14 Oct 2009, Jud Craft wrote:
What about using LVM to store a pre-update snapshot of your distro?
(Separate root partition from /home and other stuff, of course. Roll
back root).
Highly inconvenient, but it would theoretically work...
It doesn't really help you when your data is
What about using LVM to store a pre-update snapshot of your distro?
(Separate root partition from /home and other stuff, of course. Roll
back root).
Highly inconvenient, but it would theoretically work...
On Wed, Oct 14, 2009 at 11:54 AM, Seth Vidal wrote:
>
>
> On Wed, 14 Oct 2009, Mike McGra
On Wed, 14 Oct 2009, Mike McGrath wrote:
I've suggested this very thing in a F-A-B thread this week. We,
packagers, have no way to fix a mistake and very few things preventing us
from making them:
https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html
Seriously:
On Wed, 14 Oct 2009, Alex Hudson wrote:
> On 14/10/09 15:31, Jesse Keating wrote:
> > On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> >
> > > The problem isn't GLODA and smart folders, it's that we have no process in
> > > place to identify and deal with problems like this before it's too
On Wed, 14 Oct 2009, Alex Hudson wrote:
On 14/10/09 15:31, Jesse Keating wrote:
On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
The problem isn't GLODA and smart folders, it's that we have no process in
place to identify and deal with problems like this before it's too late.
Aside
On 14/10/09 15:31, Jesse Keating wrote:
On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
The problem isn't GLODA and smart folders, it's that we have no process in
place to identify and deal with problems like this before it's too late.
Aside from updates-testing you mean, where people
20 matches
Mail list logo