Re: iolanguage packaging
Richard Laager wrote:
1. Some addons' shared libraries have dependencies to other addons.
Do you have an example here?It seems like this is violating the addon abstraction, though I know nothing about this programming language. For
example, I don't think I've ever seen a Perl or Python module that
required a shared library from another module; they would just require
the module itself and work with the Perl/Python API.
In Io, addons always provide a new data type that can have an additional
C API. The OpenGL addon, for example, links to the Image addon in order
to use its C-level API for accessing image data. The main reason for
providing this kind of interface is probably efficiency. Io is very much
geared towards being embedded.
If these addons are all built from the same source package, you're
probably fine. If they don't, then I'm guessing you'll need to make that
into a versioned shared library.
They all belong to the base distribution tarball, so that's not a
problem until people start to distribute addons separately.
[ Images in /usr/lib/ ]
If the images take up significant size, you should split them into an
architecture independent package. You could install these
into /usr/share and then either patch the addon to use them from there
or make symlinks.
I also think that's a good solution. Doesn't require patching upstream sources and will (hopefully) not break anything.
[ Font duplicates ]
If they're exact duplicates, I'd say you should use the existing
packages. You could see about patching the addon to use .ttf files from
the system location. This would be ideal, I think, as then it could use
other installed fonts that the upstream addon package didn't ship,
right?
Patching upstream would be possible, but it would probably a big patch
that would never be accepted upstream because Io has to support Mac and
Windows, too. The Right Thing would probably be writing a FontConfig
addon (using freedesktop's fontconfig) and making Flux support it, but
that's rather a long-term goal.
Using symlinks to standard fonts is possible and the most simple way to
go. The downside is the dependency on filenames and paths inside font
packages. I hope those don't change very often.
Thank you very much for your feedback!
Regards,
Jonas Eschenburg
Reply to: