On Wed, Nov 29, 2006 at 08:00:55AM +0100, Jesus Climent wrote: > On Tue, Nov 28, 2006 at 09:26:28PM -0600, John Goerzen wrote: > > > > Debian should do one of the following: > > > > c) Depend on both and prefer one > > Wait! > > We already do that: we depend in both of them and prefer the one listed the > first.
No, I meant you really depend on *both*. The current situation depends on one or the other. > This is out of scope for etch, so I guess the ideal solution at the moment > would be to upload with high a package that removes one of the dependencies, > but then again it creates another problem: if a package conflicts on that > dependency we have a broken trac or a broken "other application". I can't imagine that there would be a conflict on python-pysqlite2. I would really suggest depending on that one only, remove the sqlite autodetection code so that pysqlite2 is always used, and do a preinst-time warning to people that may have been using sqlite2 with trac under previous versions with an opportunity to abort the upgrade at that time so they can migrate to sqlite3. AFAIK, there is no need to support sqlite2 today. > Maybe a note under README.Debian with instructions of dump/restore in case > someone ends up pivoting packages is needed. That would be good too. Here's another scenario: Joe User is running trac, and it's using python-sqlite because he already had some other package that needs it installed. He goes to install a new package that uses Sqlite3, and python-pysqlite2 gets installed along with it. Then, poof, trac is broken. No apt warning, no nothing. It's a very unpleasant upgrade. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
