tech-pkg archive

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

Re: make modular X11 the default on NetBSD



On Wed, May 16, 2012 at 1:08 AM, Jeremy C. Reed <reed%reedmedia.net@localhost> 
wrote:
> So I will adjust my proposal to have a second package builder that
> builds all the Xorg-using packages using X11_TYPE=modular (and no
> xsrc installed to make sure). Then we can host all three:
>
> 1) packages no X (shared)
> 2) packages using native X
> 3) packages using pkgsrc X

Building packages this way is not feasible I think due to interactions between
no-X and X packages. Well, running three bulk builds sequencially
doesn't look like
a good solution to me.

> I wonder if either of the bulk builders have intelligence of not
> building packages that use X.

In distbb you can explicitely remove some packages from bulk build,
see distbb.local.mk, for example.
All dependent packages will fail recursively.
If you mark x11-links or/and libX11 this way you'll get what you want.

> Package download tools will need to be smart to know to look in both
> places or use symlinks on the download site.

cat summary1 summary2 > summary
and then use different URLs to base directory or FILE_NAME from pkg_summary(5)
for downloading? Not a big problem.

> By the way, at one time I patched pkgsrc to add some metadata to any
> package built using X11 to identify it is an X11 component. I don't
> think I ever committed it. It can be useful since I don't think we
> currently record dependencies beyond REQUIRES.

JFYI.
0 cheusov>pkg_info -B
/srv/pkgsrc_bin/NetBSD51/2012Q1/All/ap2-py26-wsgi-3.3.tgz | grep MULTI
MULTI=PYTHON_VERSION_REQD=26 PKG_APACHE=apache2
0 0 cheusov>pkg_info -B
/srv/pkgsrc_bin/NetBSD51/2012Q1/All/ap22-py27-python-3.3.1.tgz | grep
MULTI
MULTI=PYTHON_VERSION_REQD=27 PKG_APACHE=apache22
0 0 cheusov>

Packags managers can use this this field and FILE_NAME for switching between
pkgsrc and native X packages.

But I think that it would be better to convert multivariant packages,
X11_TYPE, EMACS_TYPE
and some others to pkg options framework somehow and use single field
PKG_OPTIONS from pkg_summary(5) for this purpose.


Home | Main Index | Thread Index | Old Index