Date: Sat, 22 Mar 2008 03:56:49 +0300 From: Boris Samorodov <bsam@ipt.ru> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-emulation@FreeBSD.org Subject: Re: add LINUX_OSRELEASE to bsd.linux-rpm.mk Message-ID: <98037310@ipt.ru> In-Reply-To: <20080321115227.zkcrs6rvc4c8s004@webmail.leidinger.net> (Alexander Leidinger's message of "Fri\, 21 Mar 2008 11\:52\:27 %2B0100") References: <07011489@ipt.ru> <20080321115227.zkcrs6rvc4c8s004@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Mar 2008 11:52:27 +0100 Alexander Leidinger wrote:
> Quoting Boris Samorodov <bsam@ipt.ru> (from Fri, 21 Mar 2008 02:25:50 +0300):
> > I propose the following patch to bsd.linux-rpm.mk. It introduces a new
> > variable LINUX_OSRELEASE which is evaluated at bsd.linux-rpm.mk unless
> > it has been already defined.
> What's the big picture (in the sense of: how do you want to use it)?
Well, it were you who asked about The Big Picture. ;-)
OK, we a speaking about the day when 2.6.16 is a default value.
To say in short, I assume that this variable will be used by every
linux port (well, may be except infrastructure ports).
E.g. if someone is going to install, say print/acroread7, then the
system should detect which ports (upon which acroread depends): either
x11-toolkits/linux-pango (current 2.4.2 port) or
x11-toolkits/linux_k26-pango (future 2.6.16 port).
That may be done by using:
1) the value from compat.linux.osrelease sysctl;
2) OSREL value (e.g. if OSREL>8000XX, etc.);
3) a pre-defined value;
4) checking for a file (contents).
The first one is more strict. The system is configured (linux kernel
module loaded, compat.linux.osrelease sysctl is set). There should be
no side effects or astonishments when running a linux application.
The second one can be used but only when we get at least one branch
with non 2.4.2 linux emulation by default.
The third one may be usefull for package building/jails (though this
case needs some more investigation).
The forth one may also be used, but seems to be non-reliable:
. files tend to change their names (redhat-release, fedora-release,
etc.) and internal structure;
. files may got staled after OS upgrading and so on.
So, the value of LINUX_OSRELEASE is used to set a value to a new
variable LINUX_PORT_SUFFIX. Here is a proof of concept (though it
partially works for me). The idea (as usual is stolen from our
x11/gnome (thanks!) teams. Ah, don't pay attention to actual paths,
they are given only as examples.
-----
.if ${LINUX_OSRELEASE} == "2.6.16"
LINUX_PORT_SUFFIX= _k26
.else
LINUX_PORT_SUFFIX=
.endif
expat_FILE= ${LINUXBASE}/usr/lib/libexpat.so.0
expat_k26_FILE= ${LINUXBASE}/lib/libexpat.so.1
expat_DETECT= ${expat${LINUX_PORT_SUFFIX}_FILE}
expat_PORT= ${PORTSDIR}/textproc/linux${LINUX_PORT_SUFFIX}-expat
-----
The value ${expat_DETECT}:${expat_PORT} will be:
. ${LINUXBASE}/usr/lib/libexpat.so.0:${PORTSDIR}/textproc/linux-expat
(for LINUX_OSRELEASE other than 2.6.16);
. ${LINUXBASE}/lib/libexpat.so.1:${PORTSDIR}/textproc/linux_k26-expat
(for 2.6.16).
Then a port's Makefile may use a variable USE_LINUX_APPS to show used
linux infrastructure ports (instead of using them at XXX_DEPENDS):
-----
USE_LINUX_APPS= expat
-----
What will we get? Here you are. We get two (but not limited to "two")
groups of linux infrastructure ports. Other linux applications just
use the needed group automagically.
> Depending on the usage, it may be overkill to use it in linux-rpm.mk
> and it would be better to just use it directly when it is needed. If
> you want to use it in nearly every linux port, then sure, go ahead.
> But if it is just a handful of ports, I would like to understand the
> implications. If you have something which uses this already, just show
> it. If not, I would say we are not in a hurry to add this now and we
> can talk about it, if there's something to show.
That concept may be introduced now even before the default for
linux.osrelease is changed. Current linux infrastructure ports
may not be touched -- they'll work as usual. Other linux ports may be
transferred one-by-one. And we'll get some application testing with
new linux infrastructure ports before official annouce of the change.
That path seems to be soft and quiet, with least astonishment.
WBR
--
bsam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98037310>