[arch-general] pacman new generation

Calvin Morrison mutantturkey at gmail.com
Tue Nov 22 14:46:01 EST 2011


On 22 November 2011 14:42, C Anthony Risinger <anthony at xtfx.me> wrote:

> On Nov 22, 2011 1:30 PM, "Bernardo Barros" <bernardobarros2 at gmail.com>
> wrote:
> >
> > If I still may:
> >
> > roll-back and reproducible configuration was already proposed in the
> past?
> >
> > The idea raised by Nix devs was the a purely functional approach was a
> > way to implement it. Of course people can have similar ideas with
> > other techniques.
> >
> > If it a very practical question because I'm sure all Arch users in
> > some point or another had to do a roll-back after a complex system
> > update, and then they find themselves in a difficult situation to
> > figure out how to revert all those changes.
> >
> > Pro Audio users, for instance, might want to have their system
> > configuration in a state just before the change that broke lv2 support
> > on Ardour.
> >
> > Nix approach may be not the only one, but their ideas let people see
> > the difference between same packages build with different libs, or
> > know to set a exact system configuration more easily.
>
> The only clear way to achieve clean rollbacks is to snapshot at the FS
> level ... otherwise things get real complicated, real fast.
>
> Some packages are one-way only, eg. Pacman 3.5 upgrade to DB, and
> "rollback" means saving the original, etc ...
>
> As already touched in the thread, btrfs makes this trivial.
> `mkinitcpio-btrfs` will provide 95% of what's needed already.  The hook
> could definitely use some love but it fulfills the suggested use case
> nicely, and also allows for comparison between snapshots.
>
> C Anthony
>

Honestly I don't know how this topic got so off-topic so quickly!

I think it is obvious that pacman will not get rewritten in Haskell, so
lets just stop talking about that - arguing over languages is like arguing
over window mangers, cmon people!

Secondly, I agree that snapshots must be done at a system level. It does
not make sense to re-implement something that is already being done better
by the file system. I think the OP had some ideas about rolling changes
back, I don't think he was really familiar with ARM which handles most of
that he was worried about.

Remember, you gotta KISS it or else you'll miss it!

:-)


More information about the arch-general mailing list