add LINUX_OSRELEASE to bsd.linux-rpm.mk

[Alexander Leidinger]

Quoting Boris Samorodov <bsam at ipt.ru> (Sat, 22 Mar 2008 03:56:49 +0300):

> 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).

When I look at k26 somehow I feel some dislike, but as I don't have
any better idea... you chose the color.

> 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).

We need to ask portmgr about this. In the long term 2) should be
enough, but in case we switch the default during a stable branch (I
don't know if we do it, it may or may not be a good idea), we may stick
with the old ones for the entire branch until the version which has 2.4
as the default is not supported anymore.

> 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.

Forget 4).

> 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

LINUX_OSRELEASE_SUFFIX sounds more intuitive for mem but if you want to
stick with LINUX_PORT_SUFFIX, it's ok for me.

> 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
> -----
[...]
> 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.

I agree, this is well done. Where do we have to introduce the *_PORT
stuff? Do we need a bsd.linux.mk, or can the bsd.linux-rpm.mk be used
for this? The strict answer may be no, but do we want to be that strict?

Bye,
Alexander.

-- 
I'm frequently appalled by the low regard you Earthmen have for life.
		-- Spock, "The Galileo Seven", stardate 2822.3
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137