Mail Archives: geda-user/2015/10/07/01:46:32
On Wed, 7 Oct 2015, DJ Delorie wrote:
>
> Seeing this from the distro side, I agree with Evan. A distro will
> default to building all the glue up front, partly to ensure the user
> can do whatever they want, and partially "because they can". Even
> though the glue is dynamically loaded, the distro will still pre-build
> them all. The only options you get are whether the resulting binaries
Yup. I agree, and never said the opposite. There may be exceptions, tho,
if a specific language is not in the distro, the glue wouldn't be there
either.
> are packaged in one big package (likely) or split into one per glue
> layer (unlikely, as they'd be conservative and want to make sure the
> user isn't confused by a partial install).
I disagree on this. I see no reason why a distro would package glues of
different languages into a single big package. In debian the typical
approach is to have such independent things in independent packages and
sometime provide an optional metapackage that depends on all.
If the user wants to install a specific package, he can, but installing
all at once is easy too by installing the meta.
>
> Sometimes this can lead to problems, but this is how the distros do
> it. Given the size of a standard desktop install, I don't think this
> is a "big" problem (heh) but that's how it works.
I disagree that "that's how it works". I agree that the packager can
decide either way, but I do see tons of good examples of the "set of
small packages" approach in Debian, like:
- tons of python3-* packages instead of "install everything python
related from a single package"
- cantor-backend-* - an example of different language backends end up in
separate packages
- geany-plugin-* - same story with plugins from which a few are about
scripting languages
- a lot of other examples which are about backends and plugins (pdns,
akondi, cl-sql, libopendbx1, phonon, lcmaps, munin, shinken, just to name
a few)
I really see no reason why the same could't or wouldn't happen with gpmi.
> The case where support is added "on the fly" is a rarely used one -
> I've seen it for codecs and that's about it, and even then all the
> codes are pre-built and pre-packaged.
I disagree, I see this mechanism in action pretty often.
Codecs are good examples: as you said, they are pre-built and
pre-packaged, just like gpmi language glues are (yes, I do have debian
packages for gpmi). You can install a codec later, without recompiling the
media player.
Many of the scriptable/modular software I know of are able to load new
scripts or plugins after startup. Irc clients (ircII, irssi, bitchx, even
mirc), irc bots (eggdrop), map editor josm. Scripts written in modern
scripting languages also dynamically load code and other scripts on the
run. The Linux kernel can load and unload modules on the fly; modules
that are sometimes not even compiled locally (debian even packages some
modules like that). Many popular GUI web browser can load and unload
plugins without restart.
I think loading things on the fly is normal these days. I do use this
feature in random software from time to time and I am very happy that I
don't need to restart them for loading a plugin or a script.
Beside arguing on the statistics whether similar mechanisms are
rare or not, do you have anything against it?
Regards,
Igor2
- Raw text -