CVS commit: pkgsrc/pkgtools/x11-links

Discussion:

Thomas Klausner

2014-05-03 22:51:48 UTC

Nothing in particular about this commit, but reading it made me wonder.

pkgsrc/pkgtools/x11-links: Makefile
pkgsrc/pkgtools/x11-links/files: xorg xorg.fontconfig xorg.freetype2
xorg.glu xorg.libICE xorg.libSM xorg.libX11 xorg.libXau
xorg.libXcomposite xorg.libXdamage xorg.libXdmcp xorg.libXext
xorg.libXfixes xorg.libXfont xorg.libXft xorg.libXinerama
xorg.libXmu xorg.libXpm xorg.libXrandr xorg.libXrender xorg.libXres
xorg.libXt xorg.libXtst xorg.libXv xorg.libdrm xorg.libpciaccess
xorg.libxcb xorg.pixman xorg.xcb-util xorg.xcursor
Update to 0.89
* Support OpenBSD 5.5's Xenocara

The diffs are all adding
libfoo.so.5.0
with varying "foo", "5" and "0".

Why doesn't x11-links accept
libfoo.so.*
instead?
Thomas

OBATA Akio

2014-05-04 01:24:33 UTC

Permalink

Post by Thomas Klausner
Nothing in particular about this commit, but reading it made me wonder.

The diffs are all adding
libfoo.so.5.0
with varying "foo", "5" and "0".
Why doesn't x11-links accept
libfoo.so.*
instead?

Then, libfoo.*.dylib also will be required :)

I've added *.la expansion for Cygwin support,
lib/libfoo.a.dll, not lib/libfoo.a
bin/cygfoo.dll, not lib/libfoo.so

So no need to update files for platforms *.la are provided.

My proposed next changes are:
* Only put lib/libfoo.la entries in xorg.* files
* If libfoo.la exists, expand it (already implemented)
* Otherwise, try to expand manually
libfoo.la => libfoo.so, libfoo.so.* for SHLIB_TYPE=ELF
libfoo.la => libfoo.dylib, libfoo.*.dylib for SHLIB_TYPE=dylib
(stopping, how to determine its prefix whereas missing libfoo.la?)

Then, next proposed changes are:
* Only use x11-links for the case builtin X11 is monolithic
* Otherwise, builidlink dynamically

Because, with modular X11, we can check version of each builtin
X11 modules and can be handled individually, it is same as other
buitin package handling other than X11 related packages.

For that matter, X11_TYPE=modular is ambiguous, because buitin
X11 is modular in these days, so it should be called as
X11_TYPE=pkgsrc instead.

--
OBATA Akio / ***@lins.jp

Ryo ONODERA

2014-05-31 22:22:20 UTC

Permalink

Post by OBATA Akio

Post by Thomas Klausner
Nothing in particular about this commit, but reading it made me wonder.

pkgsrc/pkgtools/x11-links: Makefile
pkgsrc/pkgtools/x11-links/files: xorg xorg.fontconfig xorg.freetype2
xorg.glu xorg.libICE xorg.libSM xorg.libX11 xorg.libXau
xorg.libXcomposite xorg.libXdamage xorg.libXdmcp xorg.libXext
xorg.libXfixes xorg.libXfont xorg.libXft xorg.libXinerama
xorg.libXmu xorg.libXpm xorg.libXrandr xorg.libXrender
xorg.libXres
xorg.libXt xorg.libXtst xorg.libXv xorg.libdrm xorg.libpciaccess
xorg.libxcb xorg.pixman xorg.xcb-util xorg.xcursor
Update to 0.89
* Support OpenBSD 5.5's Xenocara

The diffs are all adding
libfoo.so.5.0
with varying "foo", "5" and "0".
Why doesn't x11-links accept
libfoo.so.*
instead?

Then, libfoo.*.dylib also will be required :)
I've added *.la expansion for Cygwin support,
lib/libfoo.a.dll, not lib/libfoo.a
bin/cygfoo.dll, not lib/libfoo.so
So no need to update files for platforms *.la are provided.
* Only put lib/libfoo.la entries in xorg.* files
* If libfoo.la exists, expand it (already implemented)
* Otherwise, try to expand manually
libfoo.la => libfoo.so, libfoo.so.* for SHLIB_TYPE=ELF
libfoo.la => libfoo.dylib, libfoo.*.dylib for SHLIB_TYPE=dylib
(stopping, how to determine its prefix whereas missing libfoo.la?)
* Only use x11-links for the case builtin X11 is monolithic
* Otherwise, builidlink dynamically
Because, with modular X11, we can check version of each builtin
X11 modules and can be handled individually, it is same as other
buitin package handling other than X11 related packages.
For that matter, X11_TYPE=modular is ambiguous, because buitin
X11 is modular in these days, so it should be called as
X11_TYPE=pkgsrc instead.

Looks very good idea for me.

--
Ryo ONODERA // ***@yk.rim.or.jp
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3

Greg Troxel

2014-05-31 22:43:11 UTC

Permalink

Post by Ryo ONODERA

Post by OBATA Akio
* Only use x11-links for the case builtin X11 is monolithic
* Otherwise, builidlink dynamically
Because, with modular X11, we can check version of each builtin
X11 modules and can be handled individually, it is same as other
buitin package handling other than X11 related packages.

I think we're too close to branching to do this now, but after 2014Q2 is
cut this seems perhaps ok. However, I wonder if it's really feasible to
mix and match given -L flags.

Post by Ryo ONODERA

Post by OBATA Akio
For that matter, X11_TYPE=modular is ambiguous, because buitin
X11 is modular in these days, so it should be called as
X11_TYPE=pkgsrc instead.

Looks very good idea for me.

We could change, but should accept the old "modular" for quite a while.
So this change would really be about accepting "pkgsrc" and perhaps
warning on "modular". That seems ok to me.

Joerg Sonnenberger

2014-05-31 22:57:54 UTC

Permalink

Post by OBATA Akio
For that matter, X11_TYPE=modular is ambiguous, because buitin
X11 is modular in these days, so it should be called as
X11_TYPE=pkgsrc instead.

No unnecessary churn please.

Joerg

OBATA Akio

2014-06-01 00:40:44 UTC

Permalink

Post by Joerg Sonnenberger

Post by OBATA Akio
For that matter, X11_TYPE=modular is ambiguous, because buitin
X11 is modular in these days, so it should be called as
X11_TYPE=pkgsrc instead.

No unnecessary churn please.

I know why X11_TYPE=modular is used for historic reason,
but you should consider about newbie.

--
OBATA Akio / ***@lins.jp