El dom, 02-01-2011 a las 12:41 +0100, Uwe Steinmann escribió: > Hi Francisco, > Hi Uwe. Thanks for your answer, and sorry for my late. > I'm one of the developers for about 2 month now and made most > of the recent changes to the code currently only available in > svn. > > > I am trying to package the new upstream version of mydms [1]. > > This Debian package is removed from the archive, and it won't > > be present in Squeeze [2]. > > > > The upstream package is renamed to letodms [3]. Last versions > > have a lot of changes (database, code) and improvements. > The upcoming version (probably 3.0) will have even more changes and > is much more modulized. > > > I'm not sure if it is better to rename the package, creating a > > dummy transitional package (mydms) with the new package letodms. > > Or maybe, as the old mydms is removed from archive, just doing as a > > new package, and upload it with an ITP. > The database changes are still rather minor and can be handled by > dbconfig. Yes, I agree with you. The current database upgrades are easy to manage. > The next version will have some changes in how admins and > guests are treated. Currently there is only one admin and guest > allowed. In the future any number of admins and guests are possible. It is very interesting, I suppose that you'll release an upgrade sql file or patch. If so, probably it could be used with dbconfig-common. (I going to follow your new changes in svn). > I'm not sure if dbconfig has a solution for it, because all guest > must have the 'isguest' field set in the database. > > In case of rename the package, maybe it could be needed to keep > > some paths (user data in /var/lib/mydms must remain, instead > > /var/lib/letodms), and Apache config to be compatible with old instances > > of mydms (for example, the old URL http://<server>/mydms must kept, > > maybe add the new http://<server>/letomds). > > The old mysql database name, named mydms, must be ketp to in new > > package to compatibilize with old instances of mydms. > > > > Maybe, the best way to rename the package is doing it with a new > > Debian revision with no database changes (on the same upstream > > version), and later package new upstream versions with database > > changes (db is managed with dbconfig-common). > > But, I am not sure if keep old /var/lib/mydms (for mydms upgrades) > > and create /var/lib/letodms (for new installs) is a good idea > > (it isn't). > > > > I would like to know what do you think about these points. > > Thank you. > I thought about it as well but finally created new debian packages > for letodms and droped the upgrade path from mydms, mostly because of > all the renaming you mentioned above. If that could be done automatically > it would be great, but I doubt it's worth to do so. What if Readme.Debian > just describes how to upgrade? Yes, I agree with you in create new debian package/s for letodms. This solution could be cleaner. And yes, I'll document all the upgrade process in Readme.Debian. If there is not other suggestions, I'll do this. Thank you for your comments and valuable information. Keep doing this good job with letodms :). > > The *new* letodms in debian should be split up into various packages. > The source of letodms is already prepared for such a split. The source > code has a Makefile to create a pear package of the core, a webdav > server based on HTTP_WebDAV_Server and the application itself. > There is still some fine tuning needed, but that's only a matter of time. Ok. It is very interesting. Once you release these changes, I'll study it. Thanks. Regards, Francisco. -- Francisco M. García Claramonte <franciscomanuel.garcia@hispalinux.es> Debian GNU/Linux Developer <francisco@debian.org> GPG: public key ID 556ABA51
Attachment:
signature.asc
Description: This is a digitally signed message part