Package management
Opened this issue · 9 comments
Compiling Ivy is pretty easy, as long as you already have Racket installed. But adding Ivy to the system package managers would be better still.
I can write an RPM spec easy enough, and probably even get the package added to the Fedora repos. For other Linux distros, there's the Open Build Service by OpenSUSE. For Windows, there's Chocolatey. For OS X, there's Homebrew.
One possible issue, though, is that most Linux distributions tend to frown on static linking / bundling dependencies.
I like macports as well.
I could take care of Gentoo, but the way Racket deals with libraries is different from, say, Guile. The idiomatic Racket way is to install libraries in the user's .racket directory. If I make an ebuild for racquel, this means it'd be installed into the global package space, which the user may or may not like. On the other hand, what I could do is tell raco to install racquel when building, install ivy, and then the racquel package would disappear with the rest of the chaff in the temporary build directory --- completely ignoring any racquel package that may or may not be installed onto the system already.
That seems like a pretty clever solution; you should look into standards or requirements for inclusion into various package repos regarding static linking like that.
I was thinking about investigating making a port of ivy for macports. But alas, there's no Racket port. So that's a no go as of now.
Unless, of course, we made a macports package for Racket as well. Then again, I have no idea how much effort goes into making a macports package. I have a Gentoo ebuild that may or may not be useful if that's something worth investigating.
Actually, creating a portfile doesn't look to be that much different from an ebuild. I think I can cook something up. Maybe I'll mention it on the Racket users mailing list as well.
This would be much easier if I had access to macports myself instead of guessing how things might work out.
And about Gentoo, I think it'd be worthwhile to separate the libraries from package installation. Since it's a very source-oriented distro, it makes more sense to have an ebuild for ivy as well as rsvg, racquel, etc. Debian, on the other hand, not so much. Having a single .deb containing the prebuilt binary seems just fine to me and if users want to mess around with any of ivy's dependencies, they can use raco to install them.
Except any Debian users who already have librsvg installed would run into packaging conflicts. If we were to bundle dependencies, I'd say try putting everything in a flatpak instead.
I'm not talking about packaging the librsvg.so, I'm talking about the rsvg wrapper. The deb spec would say that librsvg.so is a runtime dependency.