Mail Archives: geda-user/2015/10/07/10:17:58
On Wed, Oct 7, 2015 at 1:46 AM, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> 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.
That is a point. I mean the interpriters like python and tcl are not
built into GPMI so it is just a question of having a lot of
dependencies not a single large package.
> If the user wants to install a specific package, he can, but installing all
> at once is easy too by installing the meta.
+1
>>
>> 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.
+1
>> 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.
+1
(although in codecs it makes me worry about security)
> 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
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
- Raw text -