[02:00] <ScottL> micahg, i am presuming that at some point i will need to add "Conflicts: ..." into the new ubuntustudio packages to keep from pulling in some of the older and now unused packages
[02:01] <ScottL> for example, ubuntustudio-theme will no longer be needed, or ubuntustudio-menu, or ubuntustudio-icon-theme, etc
[02:09] <micahg> right, conflicts unless you're using transitional packages (which might help for LTS -> LTS upgrades if you support them or upgrades in general)
[02:09] <micahg> if you're using transitional packages, you'll want a versioned breaks/replaces when you switch to the transitional package
[02:44] <ScottL> by the way, i will be using your suggestion about including nautilus and thunar together for the time being
[02:45] <ScottL> i'm not sure i am get my head around how to do the transitional package correctly right now
[02:51] <ScottL> i'm not a fan of upgrades in general, especially for LTS -> LTS as they alway seems problematic
[02:52] <ScottL> however, that doesn't mean we shouldn't try to accommodate them
[02:53] <ScottL> micahg, i am familiar with transitional packages, i did one for transitioning from audio seed to audio-common, audio-generation, and audio-recording
[02:53] <ScottL> but i would appreciate a quick overview on what i might need to do
[02:53] <ScottL> i would presume that i need to make updates for the current packages that will no longer be needed, but make them depend on the new packages
[02:54] <ScottL> which will be a little weird as something like six packages are resolved into two packages now and i'm not exactly sure how that will be structured
[02:55] <ScottL> i'm also going to be a little unsure about the versioned breaks/replaces at this point
[02:55] <ScottL> let me finish mapping the changes as they are now and then i should have a better feeling about this
[02:55] <micahg> ScottL: the transitional packages are just binary entries in debian/control in the source that's taking over
[02:57] <ScottL> micahg, but is it using the same binary name as the old, deprecated binaries?
[02:58] <micahg> yes, that's how it's transitional
[02:58] <ScottL> right
[02:58] <ScottL> but with a newer version
[02:58] <micahg> well, versions usually come from the source package
[03:43] <ScottL> oh, yeah
[03:43] <ScottL> but won't this be kinda weird?  some of the current packages aren't aligned with version numbers
[03:44] <ScottL> i know that one of the currently used packages is at something like version 40, but the rest are at versions like 0.20
[03:44] <ScottL> when i do my final mapping of packages and functions i'll include version numbers too
[04:03] <micahg> ScottL: in that case, Conflicts/Replaces might be fine, let's see what the various upgrade paths are, then we can decide