Quoting Boris Samorodov (Mon, 24 Mar 2008 00:36:00 +0300):

> Alexander,
>
> thanks for your feedback.
>
> On Sat, 22 Mar 2008 08:54:34 +0100 Alexander Leidinger wrote:
> > Quoting Boris Samorodov (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.

>
> :-)
> Actually, that's your idea I played with:
> http://lists.freebsd.org/pipermail/f...ry/004380.html


Hehe... quick shot.

> Seriously, I don't like it too:
> . what if the next linux osrelease we will support appear to be
> 2.6.60?
> . what if we decide to have ports to support both, say, fc6 and f8/f9,
> etc.?
> . what if we decide to use some other linux distribution (not
> necessarily as a default) with 2.6.XX kernel?
>
> The more I think about the naming the more I return to using a linux
> distro name:
> x11-toolkits/linux-pango and x11-toolkits/linux-f8-pango .


Good idea. When I think about it it seem obvious. Seems I didn't see
the tree in the forest (this is a _very_ rough translation of a German
proverb, please bear with me, I didn't had breakfast yet).

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

>
> If we decide to use a distribution name than it may be smth like
> LINUX_DIST_SUFFIX.


Ok.

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

>
> Thanks. I even like it myself. ;-)
>
> > 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?

>
> Well, I'd prefer to use one existing file: bsd.linux-rpm.mk. If/when
> we use some other distro (I have some positive results with ubuntu)
> then may be we will have to use bsd.linux-deb.mk and split
> bsd.linux-rpm.mk into two files. But so far it's OK to me to use
> the existing one.


Ok, when we split up, we should think about a linux.mk for generic
stuff, and packaging specific mk's. Until then linux-rpm.mk should be
ok.

Bye,
Alexander.

--
Suffocating together ... would create heroic camaraderie.
-- Khan Noonian Singh, "Space Seed", stardate 3142.8
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
freebsd-emulation@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...ebsd-emulation
To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org"