# demerge - emerge the other way around

## ian!

"Gentoo is about choice", guess you heard about it at least once. That's why most of us give a lot of packages a try and probably also remove some of them afterwards. Most of us most likely will not. When I became a dev I faced one problem testing packages: 'Keeping my installation clean.' As a developer you often install a lot of packages. Lots of them are still in testing. Your day often looks like:

```
# emerge $this

($this comes with deps $bar and $baz that also get installed)

# emerge $that

(bump $this and $that version)

# emerge $this

# emerge $that

# emerge $some_deps

# USE="foo" emerge $that
```

In the end you installed a lot of stuff and your world file grows. - Wouldn't it be nice to revert all your changes with one simple command? - With demerge you can. - Lemme give a short example:

```

# emerge demerge

# demerge --record

# emerge gentoo

# demerge --record

# emerge -C DateManip
```

Calling demerge now gives:

```
# demerge

demerge version 0.029

  Use this program carefully - otherwise you might run into problems.

  You are root. You are responsible for your actions.

  Bugs and requests go to ian <ian@gentoo.org>.

  Found previous states:

    1172352506 (2007-02-24 22:28:26)

          -app-misc/gentoo-0.11.55 USE="nls -gnome -fam"

          +dev-perl/DateManip-5.44 USE=""

    1172352564 (2007-02-24 22:29:24)

          +dev-perl/DateManip-5.44 USE=""

  To revert to one of the previous system-states run 'demerge --restore timestamp'.
```

So if you want to go back to the state where 'gentoo' was not installed but 'DateManip' was type:

```
# demerge --restore 1172352506

 ..

 Packages that will be uninstalled:

  app-misc/gentoo-0.11.55 USE="nls -gnome -fam"

  

 Packages that will be installed:

  dev-perl/DateManip-5.44 USE=""

 Proceed? (y/n):
```

Type 'y' and watch demerge revert to the given system state. - Now type `demerge` again..

```
# demerge

 ...

 

 1172352506 (2007-02-24 22:28:26)

  No differences found.

 

 ...
```

Just what you expected, right? Let's see what happens if we do something different:

```
# USE="gnome" emerge gentoo

# demerge

 ...

  1172352564 (2007-02-24 22:29:24)

         -app-misc/gentoo-0.11.55 USE="nls gnome -fam"

         +app-misc/gentoo-0.11.55 USE="nls -gnome -fam"
```

See? demerge is useflag aware.

Ok great. Now you decided to like demerge and want it to record the system-state after every --sync. You can do that by:

```
# chmod +x /etc/portage/postsync.d/demerge-record
```

Now after a `emerge --sync` the current system-state will be recorded by demerge automatically so that you always have states at hand to revert to.

After some time you will have quite some stuff on your harddisk. That is when the option --wipe-older comes in handy:

```
# demerge --wipe-older 1172352506
```

Executing this will remove all stuff recorded older than the given timestamp.

Enjoy! And don't forget about `man demerge`  :Wink: 

----------

## purpler

wowwwww  

nice oneeee  :Very Happy: 

----------

## ian!

Just released demerge-0.040 which will hit the mirrors in just a few.

 *Changelog wrote:*   

> 0.040
> 
> - Speedups/Caching (in memory)
> 
> - New storage format (uses less disk space; melts down ~13MB to 60kb per state) 
> ...

 

Enjoy!

----------

## likewhoa

thanks for this fine package. will come in handy with my bloated test system.

----------

## swimmer

Will this converter be called automagically with the update? Or do we have to do this manually?

And thanks for the good work!!!

Greetz

swimmer

----------

## mudrii

ian!

Big Thank you for this one

Regards

----------

## ian!

 *swimmer wrote:*   

> Will this converter be called automagically with the update?

 

Yes. It will check for old versions and convert them automatically. (Versions recorded with <demerge-0.0.27 cannot be converted btw because these are missing useflag data. The converter will tell you about it in case you have such.)

----------

## swimmer

Thank you  :Smile: 

----------

## salam

does it also record the dependecies which are pulled in with emerging a single package?

----------

## ian!

 *salam wrote:*   

> does it also record the dependecies which are pulled in with emerging a single package?

 

Sure.

It records all package changes, which useflags are set (on a per package base) and what packages are recorded in the worldfile and which are not. When restoring a state demerge will take care of restoring all that.

----------

## sonicbhoc

Woah. Now that sounds interesting. I might give it a shot if I ever get adventurous.

----------

## ian!

demerge-0.042 is on the way..

 *Changelog wrote:*   

> 0.042
> 
> - New option --comment which allows users to leave comments on each state.
> 
> - Autocomment on states being recorded before restoring a state.
> ...

 

So - just to give a simple example - you now can do something like:

```
# demerge --record --comment='Before fixing GLSA 200703-26 [N] file: Integer underflow ( sys-apps/file )'

..

# glsa-check -f 200703-26

..

# demerge

..

 * Found previous states:

   1176926919 (2007-04-18 22:08:39) - Before fixing GLSA 200703-26 [N] file: Integer underflow ( sys-apps/file )

        -sys-apps/file-4.20 USE="python"

        +sys-apps/file-4.19 USE="python"

..
```

----------

## plut0

Curious, why is this needed when depclean is available?  Wouldn't it be better to oneshot your dependencies instead of putting them in the world file?

----------

## Kalin

 *Quote:*   

> Curious, why is this needed when depclean is available?

 

Well, one example was given above: it is useflag aware.

2nd, it remembers (ian!, thanks for --comment option) states for you, so you can revert several steps at a time.

 *Quote:*   

> Wouldn't it be better to oneshot your dependencies instead of putting them in the world file?

 

AFAIK, nothing is put in the world file, everything is stored in ~/.demerge/

----------

## ian!

 *plut0 wrote:*   

> Curious, why is this needed when depclean is available?

 

demerge does way more then depclean does.

Examples:

1.) Before being able to use depclean you would need to know which packages were installed, unmerge them manually and then call depclean.

2.) depclean relies on the dependency information provided by ebuilds. demerge does not. This makes it a lot more safe and sane in cases where ebuilds are missing vital dependency information.

3.) demerge does recall multiple states.

4.) With demerge you simply can go back in time and switch to previous states, revert them again, copy them on other machines and clone installations etc.

demerge was written with a different goal in mind than just being a better --depclean. (See my first post in this thread.)

 *plut0 wrote:*   

> Wouldn't it be better to oneshot your dependencies instead of putting them in the world file?

 

Only packages that were in world before will be recorded in world when restoring a state.

----------

## avx

Now that's a nice one, thanks! Will this be part of regular emerge at some time?

----------

## jesnow

 *ph030 wrote:*   

> Now that's a nice one, thanks! Will this be part of regular emerge at some time?

 

Second that.

J.

----------

## plut0

Another question...If you install application 'abc' that depended on say apache, which was not already installed, take a snapshot after this install.  Then you install application 'xyz' that also depended on apache and took another snapshot.  Now you want to remove application 'abc' using demerge.  Does apache get removed also?

----------

## ian!

 *plut0 wrote:*   

> Now you want to remove application 'abc' using demerge.

 

You can't. demerges purpose is to revert to previous recorded states.

demerge != depclean

----------

## plut0

Thanks, I got it now  :Smile:   Looks like a great tool!

----------

## biatch0

How does demerge deal with deprecated and/or masked packages?

----------

## ian!

 *biatch0 wrote:*   

> How does demerge deal with deprecated and/or masked packages?

 

Currently it does not care about that at all but upcoming versions will.

----------

## kfiadeg

This is a great piece of good stuff! Thank you!

Hope this will be a part of portage utils soon.

----------

## Extintor

Looks promising. Thanks a bunch!

----------

## jurrie

Thanks a lot for this. This program has saved me a great deal of pain from reverting back to my 'stable' state after doing some experiments ^_^

----------

## Kate Monster

This is extremely nifty! Well done, ian!   :Very Happy: 

----------

## ian!

One thing that was going to get on my nerves is now fixed in 0.044:

 *Changelog wrote:*   

> - Do not record states in postsync when state is identical to the latest recorded state.

 

No more redundancy when auto-recording after --sync. --- Eh. You don't know about this feature?

 *demerge-ebuild wrote:*   

> /etc/portage/postsync.d/demerge-record has been installed for convenience
> 
> If you wish for it to be automatically run at the end of every --sync simply chmod +x /etc/portage/postsync.d/demerge-record
> 
> If ever you find this to be an inconvenience simply chmod -x /etc/portage/postsync.d/demerge-record

 

Enjoy!  :Smile: 

----------

## ian!

 *Changelog wrote:*   

> 0.045
> 
> - Check if needed ebuilds are available. Show which ebuild will be used by portage when merging the package.

 

----------

## NerdIII

Sorry, that I bring back this dusty thread, but I just found this tool after another system breakage due to updates (no more hibernate, stop media key tunes down volume, system sometimes hangs on starting X) and had no easy way to revert to the previous state.

First I thought I would have to write something myself. Try to emerge to a temporary file system, record files that would be overwritten and create a backup from that. Demerge is a great alternative, thank you!

----------

## F1r31c3r

 *Quote:*   

> Use this program carefully - otherwise you might run into problems.
> 
>   You are root. You are responsible for your actions. 

 

This made me laugh, in fact it made me more than just laugh, awesome program message love it. great work  :Razz: 

----------

## Cyker

Aha! I was wracking my brain to try and remember what this util was called. I'm currently experimenting with different DE's and this tool is friggin' essential for rolling back without having to manually record and unmerge the 100+ packages that a DE normally tries to pull in.

Thank you so much for making this; It is probably the single most useful Portage tool. IMHO it should be a standard part of Portage!

----------

## Yamakuzure

 *Cyker wrote:*   

> Aha! I was wracking my brain to try and remember what this util was called. I'm currently experimenting with different DE's and this tool is friggin' essential for rolling back without having to manually record and unmerge the 100+ packages that a DE normally tries to pull in.
> 
> Thank you so much for making this; It is probably the single most useful Portage tool. IMHO it should be a standard part of Portage!

 Just a tiny little suggestion:

```
emerge --depclean
```

...will unmerge all the no longer needed dependencies.

----------

## Cyker

Yeah, I knowabout depclean, but from past experience I'm wary of it - a) You still need to record the originating packages, which aren't necessarily the ones you named, and b) Last time I used it on something with such complex dependency chains, it broke the system horribly...

demerge just *works*  :Very Happy: 

----------

## Elleni

Will demerge also restore configuration files when reverting to previous state? I come from having a problem with dovecot upgrade where etc-update did merge "trivial changes" and after that I could not login to my mailserver anymore. Fortunately I had a backup from where I could copy back /etc/dovecot content and my problem is solved. Now I would like to know if demerge can save me in a similar case to revert back to previous state including configuration files. 

Sounds very promising. Thanks.  :Smile: 

----------

