Stéphane, I'll describe what I'll have done for AltBrowser processing the relevant announcement, according to what I know of the way MC maps packages and names : System announce class category change for classA, from catB to catC. In AltBrowser / class side - Find RPackage owning catB (matching Rpackage name + tag). - Find ClassA inside RPackage/catB representation - Remove my Alt object representing ClassA from class global structure. -- Announce to all AltBrowser instances to remove their Wrapper on Alt object for ClassA - Find RPackage owning catC - Find tag catC / create if needed - Create an Alt object representing ClassA inside RPackage (and catC if package has more than one tag). -- Announce to all AltBrowser instances to add the new object if appropriate This is the core of the code I have in the browser for each announcement, more or less. I was hoping RPackage would do the right thing, which is : As long as the system still has system categories, do any operation involving system categories according to the expected semantics (and MC is, for me, the judge of what those expected semantics may be). It would be nicer to be able to scrap directly the categories; for that, I would : build a new set of tools (RPackage-based system browser) disregarding categories. Disconnect that from MC except for an initial loading (not even querying MC for the related package, hey Nautilus!). Try to work in the system by removing everything that uses categories (return to basic, new, RPackage-based browsers). Have a reverse unload to MC (propagate all changes registered in RPackage back in MC when asked for it by the developper). Have only RPackageOrganizer or MC tracking changes, but not both. Reconnect both when all is stable. If you want, I can make an AltBrowser which would be a pure RPackage / tags only System Browser, no categories. Maybe RPackage is integrating too much too early in the system. Oh, as an aside since we're tracking unwanted instances, I wonder if there isn't a leak somewhere in dependencies / announcements (which would explain the more than one RPackageOrganizer instance bug cropping up). I'm leaking, and some instances of my browser don't garbage collect. Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : samedi 8 septembre 2012 08:58 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RE : RPackage, Monticello and the removal of PackageInfo Thierry one of the problem we encountered is the following one with version 1 you have your package and tags MyPackage extensions methods... tagA classA classB tagB classC Now what do we do if the user change the category of the class. So we started to think that we should change class definition template so that we get category:'' -> package:'' tag: '' but this was implying to check in a lot of places. After we will see may be we will do it. The idea of esteban was to see if we can first get rid of PackageInfo, then in the future version of categories. Stef