tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: -nox11, -x11, -qt, -tty, etc.

Dieter Baron wrote:
In article <> Johnny wrote:
: The following packages are obvious candidates for using package options:

[long list]

: I plan on converting them to use package options instead of requiring a : separate package to handle the presence or lack of X11.

: Because people may be relying on these packages to generate binary : packages, I will keep these package directories in place with the : necessary magic to build the corresponding package. For example, with : databases/sqsh I plan on adding a "x11" option and then : databases/sqsh-x11 will install a package named "sqsh-x11" that simply : pulls in sqsh/Makefile and forces the "x11" option to be turned on. If : at a later time we decide on how we want to generate binary packages of : the same package with different options, we can remove these packages at : that time.

: Comments?

  What is the gain of doing this now?

  The only stumbling block to creating multiple binary packages for
different option sets is how to name them, and how to ensure that no
two such packages can be installed at the same time.

  I think we should attack the real problem and clean this mess up
when the infrastructure can support a clean solution.

You can think of this as a prelude to such a solution. By converting these packages, we do the first step of at least making these options in the "primary" package. We would need to do this in any Final Solution. By doing the conversions, I expect to be able to tease out a more general solution that would apply for all packages that support package options. I agree that the crux of the matter is in the naming of packages and in how that interacts with CONFLICTS and DEPENDS.

Lastly, I believe it will greatly simplify the packages so they don't need, e.g. Makefile.common, etc.


        -- Johnny C. Lam

Home | Main Index | Thread Index | Old Index