[arch-general] rubygems, the arch way and the aur

newer
[arch-general] NAS drive revisited

older
[arch-general] acpi_listen has no...

martin kalcher

19 May 2012 19 May '12

5:26 p.m.

Hey archers, i am not sure if this topic belongs to aur-devel or arch-general so i will post it here, because i think the aur-devel readers will read this list too. I think rubygems is very nice. It makes it pretty easy to manage your gems and it doesnt conflict with the "Arch way" as long as you install your gems in your $HOME. But many users want system wide available gems. Hmm, no problem with the --no-user-install switch, pretty KISS. But it violates the "Arch way" at the point, that we want to use pacman to install software, because we know and trust pacman and we dont want to use random software to install/remove files at critical locations of our systems. There are some solutions. Many people uploaded ruby-* PKGBUILDs to the AUR. Great Idea. But they are constantly out of date, because it requires some work to keep on track with rubygems.org (I am not sure if this is a correct english sentence, but i think you will get it.). So somebody wrote pacgem, wich is a ok idea, but its a little bit outdated too. I think the AUR solution is better, but we have to solve the problem with the outdated PKGBUILDs. My suggestions I wrote a simple python script that creates PKGBUILDs from the rubygems.org API. I wrote it just to figure out if this works, so its pretty straight forward and i dont want to publish it it yet. It worked quite nice - it can resolve dependencies and stuff like that - but there is one problem at the moment. The API does not provide any checksums for the gems, but i opened an feature request [0]. With this script i could imagine two things. Setting up a virtual AUR user, who handles all ruby-* packages. Then we create a rubygems account for this user, so we can create a custom rubygems feed for this user, with the gems we have in the AUR. Once a day a script checks the feed for updated gems and creates new PKGBUILDs, if needed. Pretty awesome! If it is possible to integrate this into the AUR, this would be my favorite solution. But i could imagine, that some of you will yell: 'This not what we consider KISS!' The second solution is to provide my own litte archgems website, that does exactly the same. But having this stuff at a single place (AUR) would be really cool. Let me know, what you are thinking. Cheers, ushi [0] https://github.com/rubygems/rubygems.org/issues/427

Show replies by date

Ike Devolder

19 May 19 May

5:41 p.m.

Op zaterdag 19 mei 2012 19:26:43 schreef martin kalcher:

...

Hey archers,

i am not sure if this topic belongs to aur-devel or arch-general so i will post it here, because i think the aur-devel readers will read this list too.

I think rubygems is very nice. It makes it pretty easy to manage your gems and it doesnt conflict with the "Arch way" as long as you install your gems in your $HOME. But many users want system wide available gems. Hmm, no problem with the --no-user-install switch, pretty KISS.

But it violates the "Arch way" at the point, that we want to use pacman to install software, because we know and trust pacman and we dont want to use random software to install/remove files at critical locations of our systems.

There are some solutions. Many people uploaded ruby-* PKGBUILDs to the AUR. Great Idea. But they are constantly out of date, because it requires some work to keep on track with rubygems.org (I am not sure if this is a correct english sentence, but i think you will get it.). So somebody wrote pacgem, wich is a ok idea, but its a little bit outdated too. I think the AUR solution is better, but we have to solve the problem with the outdated PKGBUILDs.

My suggestions

I wrote a simple python script that creates PKGBUILDs from the rubygems.org API. I wrote it just to figure out if this works, so its pretty straight forward and i dont want to publish it it yet. It worked quite nice - it can resolve dependencies and stuff like that - but there is one problem at the moment. The API does not provide any checksums for the gems, but i opened an feature request [0].

i would say make this sourcecode public so you can take in suggestions from others.

...

With this script i could imagine two things.

Setting up a virtual AUR user, who handles all ruby-* packages. Then we create a rubygems account for this user, so we can create a custom rubygems feed for this user, with the gems we have in the AUR. Once a day a script checks the feed for updated gems and creates new PKGBUILDs, if needed. Pretty awesome! If it is possible to integrate this into the AUR, this would be my favorite solution. But i could imagine, that some of you will yell: 'This not what we consider KISS!'

true, it might not be considered KISS, BUT it provides a KISS solution for the enduser which is in my opinion the most important. So you could create a archgems user in aur and try to get all the rubygem packages under the maintenance of this user.

...

The second solution is to provide my own litte archgems website, that does exactly the same. But having this stuff at a single place (AUR) would be really cool.

Let me know, what you are thinking.

Cheers, ushi

[0] https://github.com/rubygems/rubygems.org/issues/427

--Ike

martin kalcher

21 May 21 May

6:49 a.m.

Here [0] it is! The very very first version of archgems. It creates/updates an arch repo with some help from the rubygems API. You can put a list of gems in a config a it will populate your repo with all deps. The first few tests worked quite well, but there are some issues like the missing integrity check of the source files. For testers: The config file is expected in ~/.config/archgems cheers, ushi [0] https://github.com/ushis/archgems

Kwpolska

19 May 19 May

6:03 p.m.

On Sat, May 19, 2012 at 7:26 PM, martin kalcher wrote:

...

[snip]

My suggestions

I wrote a simple python script that creates PKGBUILDs from the rubygems.org API. I wrote it just to figure out if this works, so its pretty straight forward and i dont want to publish it it yet. It worked quite nice - it can resolve dependencies and stuff like that - but there is one problem at the moment. The API does not provide any checksums for the gems, but i opened an feature request [0].

...

python script

Are you serious? A Python script for Ruby gems?! But seriously, a great idea and an even better scripting language choice.

...

With this script i could imagine two things.

Setting up a virtual AUR user, who handles all ruby-* packages. Then we create a rubygems account for this user, so we can create a custom rubygems feed for this user, with the gems we have in the AUR. Once a day a script checks the feed for updated gems and creates new PKGBUILDs, if needed. Pretty awesome! If it is possible to integrate this into the AUR, this would be my favorite solution. But i could imagine, that some of you will yell: 'This not what we consider KISS!'

And others will yell "Patches welcome." I always wanted to say that, therefore PATCHES WELCOME. But seriously, TUs/Developers/what-you-have are too lazy to do it themselves, and therefore you must learn PHP (can't call it a programming language, nor a scripting one, it's a PIECE OF SHIT), write appropriate code (good luck!), create a git-formatted patch and post it. Or find a better way to integrate it into the AUR. -- Kwpolska http://kwpolska.tk stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16 | Arch Linux x86_64, zsh, mutt, vim. # vim:set textwidth=70:

Paul Gideon Dann

10:08 p.m.

On Saturday 19 May 2012 20:03:11 Kwpolska wrote:

...

On Sat, May 19, 2012 at 7:26 PM, martin kalcher

...
python script

Are you serious? A Python script for Ruby gems?! But seriously, a great idea and an even better scripting language choice.

Oh dear oh dear; that won't do at all. Who can seriously *want* to use Python? (Just teasing, people!) I can't help much with Python code, but I might be able to help with a Ruby implementation. I suspect rubygems probably has some code we could hook into to make things easier, actually. The PKGBUILDs would be pretty trivial, I think; I wonder if it's even worth flooding AUR with them. I like the idea of a proper [rubygems] repository, containing repackaged gem files, or simply having them appear in [community]. I'm generally pretty happy using rubygems for system-wide gems, though. It doesn't bother me too much. Paul

martin kalcher

20 May 20 May

1:58 a.m.

Am 20.05.2012 00:08, schrieb Paul Gideon Dann:

...

On Saturday 19 May 2012 20:03:11 Kwpolska wrote:

...
On Sat, May 19, 2012 at 7:26 PM, martin kalcher

...
python script

Are you serious? A Python script for Ruby gems?! But seriously, a great idea and an even better scripting language choice.

Oh dear oh dear; that won't do at all. Who can seriously *want* to use Python? (Just teasing, people!)

I can't help much with Python code, but I might be able to help with a Ruby implementation. I suspect rubygems probably has some code we could hook into to make things easier, actually.

The PKGBUILDs would be pretty trivial, I think; I wonder if it's even worth flooding AUR with them. I like the idea of a proper [rubygems] repository, containing repackaged gem files, or simply having them appear in [community].

The [rubygems] repo was my first idea too. But at the moment i have no access to an arch server to build the packages and provide the repo. I dont want to build them on my local machine and rsync the packages. Hmm.. i will figure out what makepkg actually needs to build the gem packages. Does it call pacman, when i call it with -d? This would a problem in my case.

...

I'm generally pretty happy using rubygems for system-wide gems, though. It doesn't bother me too much.

Paul

Kwpolska

11:27 a.m.

On Sun, May 20, 2012 at 3:58 AM, martin kalcher wrote:

...

Hmm.. i will figure out what makepkg actually needs to build the gem packages. Does it call pacman, when i call it with -d? This would a problem in my case.

-d DOES call pacman, but you can modify makepkg in order to (a) not do so; (b) work under another distro (that won't be too hard, because:)

...

# file -i does not work on Mac OSX unless legacy mode is set export COMMAND_MODE='legacy' -- makepkg; lines 37-38

And in terms of the "-d calls pacman" thing, here comes output from a modded makepkg, with $PACMAN (variable holding pacman command) replaced with 'echo PACMAN': every time. Run under Arch, as I don't have access to other distros. (yes, my shell server is running Arch. No, it isn't my idea. But it is awesome.) And in case you ask: this is ruby-jekyll with a different name. I had to drop all the building, because my server doesn't have ruby. [kwpolska@*** testpkg]% makepkg-kw -d PACMAN ==> Making package: testpkg 0.11.2-1 (Sun May 20 13:11:07 CEST 2012) ==> WARNING: Skipping dependency checks. ==> Retrieving Sources... -> Found jekyll-0.11.2.gem -> Found LICENSE ==> Validating source files with md5sums... jekyll-0.11.2.gem ... Passed LICENSE ... Passed ==> Extracting Sources... ==> Removing existing pkg/ directory... ==> Entering fakeroot environment... PACMAN ==> Starting build()... BUILD, my server unfortunately doesn't have ruby ==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... -> Stripping unneeded symbols from binaries and libraries... ==> Creating package... -> Generating .PKGINFO file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: testpkg 0.11.2-1 (Sun May 20 13:11:09 CEST 2012) [kwpolska@*** testpkg]% If anyone from the makepkg team is reading, would you please mind: (a) making less use of pacman; (b) adding -v on lines 1292-1295 in order to inform us that the compressors are still working? -- Kwpolska http://kwpolska.tk stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16 | Arch Linux x86_64, zsh, mutt, vim. # vim:set textwidth=70:

Allan McRae

11:39 a.m.

On 20/05/12 21:27, Kwpolska wrote:

...

On Sun, May 20, 2012 at 3:58 AM, martin kalcher wrote:

...
Hmm.. i will figure out what makepkg actually needs to build the gem packages. Does it call pacman, when i call it with -d? This would a problem in my case.

-d DOES call pacman,

WRONG.

...

but you can modify makepkg in order to (a) not do so; (b) work under another distro (that won't be too hard, because:)

...
# file -i does not work on Mac OSX unless legacy mode is set export COMMAND_MODE='legacy' -- makepkg; lines 37-38

And in terms of the "-d calls pacman" thing, here comes output from a modded makepkg, with $PACMAN (variable holding pacman command) replaced with 'echo PACMAN': every time. Run under Arch, as I don't have access to other distros. (yes, my shell server is running Arch. No, it isn't my idea. But it is awesome.)

And in case you ask: this is ruby-jekyll with a different name. I had to drop all the building, because my server doesn't have ruby.

[kwpolska@*** testpkg]% makepkg-kw -d PACMAN ==> Making package: testpkg 0.11.2-1 (Sun May 20 13:11:07 CEST 2012) ==> WARNING: Skipping dependency checks. ==> Retrieving Sources... -> Found jekyll-0.11.2.gem -> Found LICENSE ==> Validating source files with md5sums... jekyll-0.11.2.gem ... Passed LICENSE ... Passed ==> Extracting Sources... ==> Removing existing pkg/ directory... ==> Entering fakeroot environment... PACMAN ==> Starting build()... BUILD, my server unfortunately doesn't have ruby ==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... -> Stripping unneeded symbols from binaries and libraries... ==> Creating package... -> Generating .PKGINFO file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: testpkg 0.11.2-1 (Sun May 20 13:11:09 CEST 2012) [kwpolska@*** testpkg]%

If anyone from the makepkg team is reading, would you please mind: (a) making less use of pacman;

You are doing it wrong... Remove the "run_pacman" function and you will see when it is called. Hint: never when using -d...

...

(b) adding -v on lines 1292-1295 in order to inform us that the compressors are still working?

Huh... Anyway, never by default, but you will be able to configure the compression options with pacman-4.1. Allan

Kwpolska

11:53 a.m.

On Sun, May 20, 2012 at 1:39 PM, Allan McRae wrote:

...

On 20/05/12 21:27, Kwpolska wrote:

...
On Sun, May 20, 2012 at 3:58 AM, martin kalcher wrote:

...
Hmm.. i will figure out what makepkg actually needs to build the gem packages. Does it call pacman, when i call it with -d? This would a problem in my case.

-d DOES call pacman,

WRONG.

...
but you can modify makepkg in order to (a) not do so; (b) work under another distro (that won't be too hard, because:)

...
# file -i does not work on Mac OSX unless legacy mode is set export COMMAND_MODE='legacy' -- makepkg; lines 37-38

And in terms of the "-d calls pacman" thing, here comes output from a modded makepkg, with $PACMAN (variable holding pacman command) replaced with 'echo PACMAN': every time. Run under Arch, as I don't have access to other distros. (yes, my shell server is running Arch. No, it isn't my idea. But it is awesome.)

And in case you ask: this is ruby-jekyll with a different name. I had to drop all the building, because my server doesn't have ruby.

[kwpolska@*** testpkg]% makepkg-kw -d PACMAN ==> Making package: testpkg 0.11.2-1 (Sun May 20 13:11:07 CEST 2012) ==> WARNING: Skipping dependency checks. ==> Retrieving Sources... -> Found jekyll-0.11.2.gem -> Found LICENSE ==> Validating source files with md5sums... jekyll-0.11.2.gem ... Passed LICENSE ... Passed ==> Extracting Sources... ==> Removing existing pkg/ directory... ==> Entering fakeroot environment... PACMAN ==> Starting build()... BUILD, my server unfortunately doesn't have ruby ==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... -> Stripping unneeded symbols from binaries and libraries... ==> Creating package... -> Generating .PKGINFO file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: testpkg 0.11.2-1 (Sun May 20 13:11:09 CEST 2012) [kwpolska@*** testpkg]%

If anyone from the makepkg team is reading, would you please mind: (a) making less use of pacman;

You are doing it wrong... Remove the "run_pacman" function and you will see when it is called. Hint: never when using -d...

I am aware of that, too. I thought it failed to work and therefore tried that way.

...

...
(b) adding -v on lines 1292-1295 in order to inform us that the compressors are still working?

Huh... Anyway, never by default, but you will be able to configure the compression options with pacman-4.1.

And that's awesome. (normally I just modify the xz line, but I need to do it every time pacman updates itself)

...

Allan

-- Kwpolska http://kwpolska.tk stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16 | Arch Linux x86_64, zsh, mutt, vim. # vim:set textwidth=70:

martin kalcher

21 May 21 May

12:13 a.m.

Am 20.05.2012 13:39, schrieb Allan McRae:

...

On 20/05/12 21:27, Kwpolska wrote:

...
On Sun, May 20, 2012 at 3:58 AM, martin kalcher wrote:

...
Hmm.. i will figure out what makepkg actually needs to build the gem packages. Does it call pacman, when i call it with -d? This would a problem in my case.

-d DOES call pacman,

WRONG.

...
but you can modify makepkg in order to (a) not do so; (b) work under another distro (that won't be too hard, because:)

...
# file -i does not work on Mac OSX unless legacy mode is set export COMMAND_MODE='legacy' -- makepkg; lines 37-38

And in terms of the "-d calls pacman" thing, here comes output from a modded makepkg, with $PACMAN (variable holding pacman command) replaced with 'echo PACMAN': every time. Run under Arch, as I don't have access to other distros. (yes, my shell server is running Arch. No, it isn't my idea. But it is awesome.)

And in case you ask: this is ruby-jekyll with a different name. I had to drop all the building, because my server doesn't have ruby.

[kwpolska@*** testpkg]% makepkg-kw -d PACMAN ==> Making package: testpkg 0.11.2-1 (Sun May 20 13:11:07 CEST 2012) ==> WARNING: Skipping dependency checks. ==> Retrieving Sources... -> Found jekyll-0.11.2.gem -> Found LICENSE ==> Validating source files with md5sums... jekyll-0.11.2.gem ... Passed LICENSE ... Passed ==> Extracting Sources... ==> Removing existing pkg/ directory... ==> Entering fakeroot environment... PACMAN ==> Starting build()... BUILD, my server unfortunately doesn't have ruby ==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... -> Stripping unneeded symbols from binaries and libraries... ==> Creating package... -> Generating .PKGINFO file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: testpkg 0.11.2-1 (Sun May 20 13:11:09 CEST 2012) [kwpolska@*** testpkg]%

If anyone from the makepkg team is reading, would you please mind: (a) making less use of pacman;

You are doing it wrong... Remove the "run_pacman" function and you will see when it is called. Hint: never when using -d...

Thanks for the info! I will try that on a centos box.

...

...
(b) adding -v on lines 1292-1295 in order to inform us that the compressors are still working?

Huh... Anyway, never by default, but you will be able to configure the compression options with pacman-4.1.

Allan

martin kalcher

20 May 20 May

1:48 a.m.

Am 19.05.2012 20:03, schrieb Kwpolska:

...

On Sat, May 19, 2012 at 7:26 PM, martin kalcher wrote:

...
[snip]

My suggestions

I wrote a simple python script that creates PKGBUILDs from the rubygems.org API. I wrote it just to figure out if this works, so its pretty straight forward and i dont want to publish it it yet. It worked quite nice - it can resolve dependencies and stuff like that - but there is one problem at the moment. The API does not provide any checksums for the gems, but i opened an feature request [0].

...
python script

Are you serious? A Python script for Ruby gems?! But seriously, a great idea and an even better scripting language choice.

Ahaha, i wrote it in Python, because i thought that the AUR is a django site.

...

...
With this script i could imagine two things.

Setting up a virtual AUR user, who handles all ruby-* packages. Then we create a rubygems account for this user, so we can create a custom rubygems feed for this user, with the gems we have in the AUR. Once a day a script checks the feed for updated gems and creates new PKGBUILDs, if needed. Pretty awesome! If it is possible to integrate this into the AUR, this would be my favorite solution. But i could imagine, that some of you will yell: 'This not what we consider KISS!'

And others will yell "Patches welcome." I always wanted to say that, therefore

PATCHES WELCOME.

But seriously, TUs/Developers/what-you-have are too lazy to do it themselves, and therefore you must learn PHP (can't call it a programming language, nor a scripting one, it's a PIECE OF SHIT), write appropriate code (good luck!), create a git-formatted patch and post it. Or find a better way to integrate it into the AUR.

Hmm PHP, ok, great.. I figured out that it is not necessary to integrate it directly into the AUR. Its possible to upload the packages through the script.

4370

Age (days ago)

4372

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Allan McRae
Ike Devolder
Kwpolska
martin kalcher
Paul Gideon Dann