[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