Am Mittwoch 21 Oktober 2009 15:19:07 schrieb Martin Paljak: > 1. For starters, we should rename the "main slogan" of OpenSC to > something that's more up to date. The "supported cards" list could > either be generalized or at least updated: > http://packages.ubuntu.com/karmic/opensc
ubuntu does not fix bugs. at least my statistic of bugs reported with patches, testing and whatever else is possible vs. work accepted by ubuntu is terrible. so the best way to get any change into ubuntu is via the upstream debian maintainer. and you need to be aware that it takes a few days for the debian maintainer to build a new package and put it into unstable, a few weeks till it is migrated to testing if no major issues are found. and that needs to be done about 5 months before an ubuntu release, because ubuntu seems to have one major "lets get new stuff from debian" action during each release cycle, and after that is over it is hard to get new versions into ubuntu. thats my experience, ymmw. > 2. Keep the main name OpenSC. This > includes any binary installers, which we should provide, if possible, to > those who are used to binary installers (Windows, OS X). This also means > getting rid of SCA/SCB. 3. Keep OpenSC core platform-agnostic: > OpenSC.tokend lives outside of the (lib)opensc package, so should the > possible future MS BaseCSP > piece, which is in nature similar to the tokend. The only cross- > platform "public interface" is PKCS#11. OpenSC *installers* for those > platforms, on the other hand, must contain those components. This > means getting rid of SCA/SCB, providing OpenSC installers for Mac and > Windows and either providing the separate user software as extra > downloadables or work with other software providers to add support for > OpenSC/PKCS#11. This is way easier if OpenSC declares somewhere what > it installs, where and why, instead of providing kitchen-sink > installers that try to do everything. my opinion on this differs. users are terrible confused if we show them a dozend or half a dozend packages, and no amount of faqs and documentation will really help to make it easy for them to pick the ones they need. a big fat package with several options inside on the other hand is standard for windows: they can pick normal/minimal/everything options or fine tune the components (but rarely anyone does), and they are used to this kind of installers. so my experience is, that is much easier for end users than a collection of small packages. on source side however, we can have several small packages, as that is more flexible for maintance, doesn't create unwanted dependencies, unless someone wants to compile those other things, and those building binaries (both distribution and our mac os X and windows packagers) know very well how to cope with many small modules, one or two extra modules won't be a big issue, I guess. Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
