Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Dec 2008 23:26:07 +0100
From:      Nikola =?UTF-8?B?TGXEjWnEhw==?= <nikola.lecic@anthesphoria.net>
To:        Romain =?UTF-8?B?VGFydGnDqHJl?= <romain@blogreen.org>
Cc:        FreeBSD-wip-status@FreeBSD.org, FreeBSD-ports@FreeBSD.org
Subject:   Re: TeXLive
Message-ID:  <20081224232607.43ea938a@anthesphoria.net>
In-Reply-To: <20081224131012.GA8392@blogreen.org>
References:  <20081224131012.GA8392@blogreen.org>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Hello Romain,

Thank you for the interesting analysis and for renewing the discussion
about TeXLive on FreeBSD.

On Wed, 24 Dec 2008 14:10:12 +0100
Romain Tarti=C3=A8re <romain@blogreen.org> wrote:

[...]=20

> 1. TeXLive should be very modular
>=20
> 	It is then possible to run a  version of XeTeX more recent
> 	then the one provided with TeXLive (i.e. compile TeXLive
> 	--without-xetex and depend on a port print/xetex-devel).

[...]

> If we consider that ports are build from source, it important to know
> that TeXLive provide a single tarball for all applications binaries
> source code. All the rest (macros, fonts, etc.) is provided as a lot
> of small tarball.  As a consequence, I see #1 as =C2=AB Split the
> applications =C2=BB, and #2, #3 and #4 as =C2=AB Split the rest =C2=BB. B=
ut maybe
> the question is more about =C2=AB Split both =C2=BB.
>=20
> For now, I do not intend to make the port that install all binaries a
> meta-port (so no #1).  It is quite huge and complex, include modified
> version of libraries that are statically linked to the binaries, ...
> well, I don't want to spend time on this right now (maybe in the
> future but unsure =E2=80=94 However, contributions are welcomed).

(I am the one who wrote #1.) What do you exactly mean by making a
meta-port for binaries? To make a port for every binary group provided
in their source tree? Sounds interesting, although what I meant there
was to use the internal TeXLive build options, such as --without-xetex,
so it's basically as simple as any of WITH_* options used in thousands
of existing ports.

> 3. One port per Package, grouping related packages (e.g. foo,
>    foo.source and foo.doc) (/[0-9]{4}/ ports) + meta-port for
>    Collections (84 meta-ports) + meta-port for Scheme (10 meta-ports)
>   + high granularity;
>   + no conflict;
>   - many ports.

The main thing with TeXLive is that they make releases once a year. My
opinion is that if we just stick with their releases -- we don't need
any fine-grained work because such year-long cemented code somehow
contradicts the idea of FreeBSD's flexible ports. The idea is to
provide porters a flexible TeXLive base that can be enriched with many
TeX-related projects that are not included in current TeXLive
distribution (new and updated LaTeX packages, new versions of TeX
extensions, etc).

Once an initial TeXLive ports structure is committed, I'd like to see
many porters grabbing parts of their particular areas of interest (or
creating -devel ports) in order to provide users with versions newer
than those initially included.

It seems to me that your your proposal #3 supports this approach.

Best regards.
- --=20
Nikola Le=C4=8Di=C4=87 =3D =D0=9D=D0=B8=D0=BA=D0=BE=D0=BB=D0=B0 =D0=9B=D0=
=B5=D1=87=D0=B8=D1=9B
fingerprint : FEF3 66AF C90E EDC3 D878  7CDC 956D F4AB A377 1C9B
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iJwEAQEDAAYFAklStwQACgkQ/MM/0rYIoZiFhQQApUO7pofWE19GskMfQ34GRWSQ
f5+AKlGvf2JKcMpB9Z0eq3aksIhxYFESAMwoEdWd+g0Z4gkyE9NdA4RCGflASahM
yaqnLsf8Ri2C0QcXbUdgufE49Yw1coGOkPT3TklB5NL2TVY+2PGJ/FfnxznU7pNY
CdeiNOZicsIRXfyUV/Q=3D
=3Dlp2b
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081224232607.43ea938a>