[Ugh, apologies for not having got back to this sooner] On Fri, 2013-03-29 at 21:20 +0100, Sebastian Reichel wrote: > 1. uploading an older fso-specs version to sid, which should avoid > the API change. Let fso-specs migrate to wheezy and ignore the > bug in libfso-glib. > 2. uploading an older fso-specs version to sid, which should avoid > the API change. Then fix the libfso-glib package. Then both > should be able to migrate to testing. > 3. use the new API, and binNMU all packages depending on it. > 4. ignore everything for wheezy > 5. remove the FSO/SHR stack from testing (libfso-glib is a reverse > dependency for almost all components) > > Option 1 doesn't make much sense, since fixing the bug in > libfso-glib should be easy with a matching fso-specs.
Well, it would mean we had the source for the files in libfso-glib, even if we weren't actually using it? > I guess it's too late in the release process for option 3. Yes. > Personally I would prefer solution 4. It's not like there is no > source at all - upstream delivers libfso-glib with the pregenerated > code. Previously this kind of code had been written by hand without > the xml abstraction anyway. > > Option 5 is also a possibility. The FSO/SHR stack is not that > popular. According to popcon there are 10 users. For the record, that appears to mean the removal of: fso-specs libfso-glib fso-datad fso-deviced fso-gsmd fso-usaged libfsoresource libphone-ui libphone-ui-shr phonefsod phoneuid fso-frameworkd phoneui-apps libshr-glib fso-gpsd openbmap-logger Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
