Date: Sat, 22 Mar 2008 12:29:28 +0100 From: Patrick Hurrelmann <outi@bytephobia.de> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-emulation@FreeBSD.org Subject: Re: add LINUX_OSRELEASE to bsd.linux-rpm.mk Message-ID: <20080322122928.6435f7fe@duality> In-Reply-To: <20080322085434.10838040@deskjail> References: <07011489@ipt.ru> <20080321115227.zkcrs6rvc4c8s004@webmail.leidinger.net> <98037310@ipt.ru> <20080322085434.10838040@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Mar 2008 08:54:34 +0100
Alexander Leidinger <Alexander@Leidinger.net> wrote:
> Quoting Boris Samorodov <bsam@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.
Hi everybody,
just a quickshot to the upcoming naming conventions (imho this popped
up several times now). I don't like the naming "k26" very much, too.
Maybe it would be enough to suffix the linux prefix only by the kernel
version? E.g. linux26-pango
This would look much saner and omitting the k (for kernel) should be
fine, also. Strictly, the linux version is the kernel version ;)
This is just a opinion from a normal user and consider it as a hint :)
Regards,
Patrick
--
====================================================================
Patrick Hurrelmann | "Programming today is a race between software
Mannheim, Germany | engineers striving to build bigger and better
| idiot-proof programs, and the Universe trying
outi@bytephobia.de | to produce bigger and better idiots. So far,
www.bytephobia.de | the Universe is winning." - Rich Cook
/"\
\ / ASCII Ribbon Campaign
X against HTML email & vCards
/ \
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080322122928.6435f7fe>