ncmpcpp-git and its users' feature requests

rich_o · 2009-09-07 11:01:28

Hi,

i maintain the AUR-package of ncmpcpp-git. Until now, my policy regarding users' feature requests was simply to fulfil them. But now, with ncmpcpp supporting more and more stuff, different users want different things, which exclude each other. But because i maintain this package for the community and not myself, i think it should be up to you, where it's going.
So, dear users of ncmpcpp-git, how should i proceed? I can think of three posibilities:

1. Stay with the default configuration, so you have to complain to the ncmpcpp developer if something is not on by default. This would remove the clock and the visualization. Fetching lyrics would depend on an preinstalled curl.
2. Enable extra stuff as long as it doesn't add new dependencies. Visualization would be gone, fetching lyrics would depend on a preinstalled curl here, too.
3. Your ideas.

So, take a stand!

rich_o

Last edited by rich_o (2009-09-21 16:43:07)

litemotiv · 2009-09-07 11:08:46

1 would be the Arch (vanilla) way, but i can also support 2

Runiq · 2009-09-07 11:45:57

I'd stick with the vanilla package. It's in the AUR, after all, and new features are just a rebuild away. If people want additional things as a default, they can still ask the developer.

Asgaroth · 2009-09-07 11:52:25

I would also prefer either option 1 or 2, but I think that adding an additional dependency for a marginal non-default feature is a bad idea.

Last edited by Asgaroth (2009-09-07 11:53:33)

tadzik · 2009-09-07 12:28:16

I'm for option 2
Regards

Allan · 2009-09-07 12:41:27

Can you make use of optdepends?

firecat53 · 2009-09-07 14:50:47

Option 2 sounds like a reasonable default.

harryNID · 2009-09-08 01:23:15

First off,

Thank you for posing this to us "The Users". It's much appreciated that you ask us our opinions as well.

I was recently thinking of this very question after getting the new version and having to turn off and get rid of all the extra stuff.

I vote for 1 but could live with 2.

A quick question (and I'll probably be yelled at by the gurus) but why not post the extra options and configure commands (enable/disable) along with the extra dependencies needed in the comments section for the program. That way if somebody does want to add the new functions (with its corresponding dependencies) then it's mostly a matter of changing the PKGBUILD slightly to suit his/her taste. That's just a thought though? Seems like it would save having to see thirty slightly different version of the same package in AUR.

Last edited by harryNID (2009-09-08 01:25:11)

SpeedVin · 2009-09-08 17:23:43

harryNID wrote:

First off,
Thank you for posing this to us "The Users". It's much appreciated that you ask us our opinions as well.
I was recently thinking of this very question after getting the new version and having to turn off and get rid of all the extra stuff.
I vote for 1 but could live with 2.
A quick question (and I'll probably be yelled at by the gurus) but why not post the extra options and configure commands (enable/disable) along with the extra dependencies needed in the comments section for the program. That way if somebody does want to add the new functions (with its corresponding dependencies) then it's mostly a matter of changing the PKGBUILD slightly to suit his/her taste. That's just a thought though? Seems like it would save having to see thirty slightly different version of the same package in AUR.

+1.
I'm voting for option 1 but 2 will be good too

ajonat · 2009-09-10 03:24:03

Hi, rich_o!
Could I ask you to include a commented line with the visualizer options and everything else in the PKGBUILD so as we, who would like to use the visualizer, could just uncomment that line (and comment the original configure line) and build with all the options?
Thanks!

unK · 2009-09-10 10:42:56

rich_o, note that visualizer itself doesn't bring any additional dependency. fftw is needed for frequency spectrum mode, sound wave doesn't require it, so you can safely enable visualizer without adding fftw to dependencies. in this case if configure script finds fftw libs/headers, ncmpcpp will be compiled with its support and frequency spectrum mode will be available, otherwise not.

Last edited by unK (2009-09-10 14:14:46)

litemotiv · 2009-09-18 19:35:39

so, we're 11 days further and fftw is still a dependency?

rich_o · 2009-09-21 10:20:41

Thank you all for your comments.

I'll go with option 2 and enable options as long as they don't install new dependencies. So, lyric fetching depends on installed curl, tag editing on installed taglib and spectrum mode visulization on installed fftw. visualization, outputs and clock are enabled.

rich_o

Last edited by rich_o (2009-09-21 10:22:00)

nixtrian · 2009-11-25 19:39:13

IMHO, using optdepends in aur package isn't right because I see the message about optional dependencies after (building and) installing the package, but if I haven't install the dependency before building - the feature becomes off.

ataraxia · 2009-11-25 19:50:15

nixtrian wrote:

IMHO, using optdepends in aur package isn't right because I see the message about optional dependencies after (building and) installing the package, but if I haven't install the dependency before building - the feature becomes off.

Technically, you're required to read AUR PKGBUILDs before using them anyway, so you'll see the optdepends then. I'd say no problem using them.

milomouse · 2009-11-25 20:04:43

Well, I like having the optdepends stuff, because I always edit the package build before I install it. And if I'm in the PKGBUILD and see an optdepend that I want, I'll either close the PKGBUILD and install what I wanted, or open a new terminal and install it there before I exit the PKGBUILD for ncmpcpp-git.

Anyway, I like the current PKGBUILD of ncmcpp-git just fine. I end up disabling "visualizations" and adding "--with-utf8". Other than that, I use CURL anyway, and I also like to edit the tag files so I leave the rest of it. Nice work.

Arch Linux

#1 2009-09-07 11:01:28

ncmpcpp-git and its users' feature requests

#2 2009-09-07 11:08:46

Re: ncmpcpp-git and its users' feature requests

#3 2009-09-07 11:45:57

Re: ncmpcpp-git and its users' feature requests

#4 2009-09-07 11:52:25

Re: ncmpcpp-git and its users' feature requests

#5 2009-09-07 12:28:16

Re: ncmpcpp-git and its users' feature requests

#6 2009-09-07 12:41:27

Re: ncmpcpp-git and its users' feature requests

#7 2009-09-07 14:50:47

Re: ncmpcpp-git and its users' feature requests

#8 2009-09-08 01:23:15

Re: ncmpcpp-git and its users' feature requests

#9 2009-09-08 17:23:43

Re: ncmpcpp-git and its users' feature requests

#10 2009-09-10 03:24:03

Re: ncmpcpp-git and its users' feature requests

#11 2009-09-10 10:42:56

Re: ncmpcpp-git and its users' feature requests

#12 2009-09-18 19:35:39

Re: ncmpcpp-git and its users' feature requests

#13 2009-09-21 10:20:41

Re: ncmpcpp-git and its users' feature requests

#14 2009-11-25 19:39:13

Re: ncmpcpp-git and its users' feature requests

#15 2009-11-25 19:50:15

Re: ncmpcpp-git and its users' feature requests

#16 2009-11-25 20:04:43

Re: ncmpcpp-git and its users' feature requests

Board footer