Re: Pulling X11 dependency out of the Erlang package.
On Fri, Sep 09, 2005 at 10:12:13AM -0400, Fran?ois-Denis Gonthier wrote:
> Hello all,
>
> I'm the erlang package maintainer. I've been suggested by someone to make an
> Erlang package that is not dependant on X11. I found that logic because an
> Erlang system node doesn't usually require an UI. But, after thinking about
> that, I saw several possible ways of reorganizing my package to accomplish
> that goal. I need to hear about what is the ideal way amongst those:
>
> - Remove the part of the main package that require X11 and put it in a new
> package. The main package could Recommend the installation of the X11
> package. I think that's not the best way as people might miss the
> recommendation of apt and later wonder where the UI toolkit has gone. Also,
> if I use this option, how should I name the new package? (erlang-x11,
> liberlang-gs [gs is the name of the toolkit], other?)
>
> - Using the previous solution, "erlang" could become a virtual package which
> would install all the usually stuff including the X11 toolkit in it's
> independent package. That way, most people would install all the required
> things and experts could install only the package they want. This idea makes
> even more sense as I may need to remove some other parts of the main
> distribution and put them in packages.
I think you have to do at least this. Someone who presently has
erlang installed, and runs apt-get update/upgrade must not end up
losing functionality, which is what would happen if all of a sudden
the erlang package all of a sudden "provided" only half of the
functionality that it did before the upgrade.
> - Make a new version of the main package with the X11 dependency removed.
> Some package works that way (example: ocaml-base vs. ocaml-base-nox).
Its not clear to me what you mean. Do you mean, build two erlang
binary packages, which Conflict: with each other, and which are the
same at the text-based level, but one additionally includes the gui
tk? This seems like a less optimal solution than the previous one.
It unnecessarily duplicates the text-based components in two packages.
Justin
Reply to: