The main reason is, as you guessed in your email, that the levels 
have no meaning at all at the dynamic_reconfigure level. The only 
place that gives them meaning is the state machine in driver_base. 
It felt unclean to me to have them in dynamic_reconfigure for that reason.

Also, driver_base is very light weight (no libraries), and is in the
same stack as dynamic_reconfigure. Therefore, depending on driver_base
is essentially free for a package that already depends on
dynamic_reconfigure.

Does that sound reasonable?

Blaise

> I had previously used the SensorLevels in driver_base, before I
> discovered the one in dynamic_reconfigure and realized I could
> eliminate the driver_base dependency. Obviously, it should only be in
> one place. But, I am not sure why you want to deprecate the
> SensorLevels in dynamic_reconfigure, since driver_base depends on it,
> not the other way around.
> 
> The extra dependency does not matter much for camera1394. We may want
> to actually use driver_base in a future version, anyway.
> 
> But, I like to avoid unnecessary dependencies, and this change seems
> to force all dynamic reconfigure users to either depend on driver_base
> or just make up their own level bits.

> Is that the idea? Levels are arbitrary and only meaningful to the
> using package? I didn't understand that when I was figuring out
> dynamic_reconfigure to begin with.