Talk:Ruby Gem package guidelines

From ArchWiki
Latest comment: 29 March 2021 by Grawlinson in topic Removing cruft

> For libraries, use ruby-gemname. For applications, use the program name.

For me it makes more sense to use ruby-$gemname for *all* packages created from gems. It makes things simpler.

Anatolik (talk) 06:52, 6 December 2013 (UTC)Reply[reply]

I agree. I already do this for several of my packages, such as ruby-adsfAUR, ruby-reekAUR, and ruby-nanocAUR.
Ichimonji10 (talk) 20:49, 7 December 2013 (UTC)Reply[reply]
Python Package Guidelines#Package naming has a similar naming convention: python-packagename for libs and packagename for applications. If the naming standard changes for Ruby packages, then the naming standard should also change for Python packages, purely for the sake of consistency.
Ichimonji10 (talk) 03:26, 9 December 2013 (UTC)Reply[reply]
I believe all other language PKGBUILD guidelines (perl/python/..) have the same rule. And all of them should be changed.
Anatolik (talk) 03:02, 10 December 2013 (UTC)Reply[reply]
I would love to see that happen. I don't know the magnitude of such a task or who would need to be convinced. Ichimonji10 (talk) 20:40, 16 December 2013 (UTC)Reply[reply]
I retract my earlier support for this proposal. I've come to see the wisdom in naming applications after the program itself. I would dislike, for example, searching the AUR or repositories for c-vsftpd or shell-git. And what about programs that are not single-language? For example, I don't think that git is comprised of a single language. Ichimonji10 (talk) 03:18, 25 June 2014 (UTC)Reply[reply]

Testing

Are there any Ruby packages that utilise PKGBUILD's check function?

Grawlinson (talk) 05:38, 29 March 2021 (UTC)Reply[reply]

Removing cruft

Is it standard practise to remove cruft from packages? Such as dotfiles (e.g. .gitlab-ci.yml) and unused directories (e.g. test/)?

I currently do this for fluentdAUR, and was wondering whether or not this was the right thing to do.

Grawlinson (talk) 05:41, 29 March 2021 (UTC)Reply[reply]