On Wed, Aug 10, 2011 at 10:55 PM, Aron Xu <happyaron...@gmail.com> wrote: > I think it depends on what additional dependencies will be pulled in > when adding the features. This requires a lot of testing, by building > the package with different settings again and again. If the dependency > is fine then there is no reason not to include the feature even if > they have relatively smaller user base.
With my proposed changes (I'll upload an updated version of conky asap to expo.d.n), the only additional dependency for conky-std is libimlib2 (+ the dependencies introduced by adding audacious and xmms2 support). > What's more, I'd like to suggest to change the names of conky > packages. The names, conky-std and conky-all, can lead users to think > the latter is greater. Since you are planning to enable more features > in the package for main, do you mind rename them to something like > conky-main and conky-contrib? Transitional package is needed. Hmmm...conky-main and conky-contrib would make less sense to Ubuntu users than the current conky-std and conky-all packages. I tend to think that conky-all refers to conky with all features enabled, and conky-std as conky with the standard feature set available, i.e. similar to what you would end up with if you ran ./configure with no other arguments (although I suppose conky-std is a bit different now, with multiple additional features enabled). In that context, I'd personally prefer the current naming scheme (but I'll remove the recommendation in conky-all's package description to install that package if the user is uncertain). I'm still open to discussion though, and I'll gladly change the names of those packages if we can come up with a set of names that makes sense for both Debian and Ubuntu, and describe those packages better than the current names. - Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
