Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Oct 2010 17:00:42 -0700
From:      Stanislav Sedov <stas@FreeBSD.org>
To:        Steve Wills <steve@mouf.net>
Cc:        cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org
Subject:   Re: cvs commit: ports/devel Makefile ports/devel/rubygem-pkg-config Makefile distinfo pkg-descr
Message-ID:  <20101012170042.71c16b03.stas@FreeBSD.org>
In-Reply-To: <4CB4F037.5030106@mouf.net>
References:  <201010120311.o9C3BhVW079967@repoman.freebsd.org> <20101012024226.2dc802a8.stas@FreeBSD.org> <4CB4F037.5030106@mouf.net>

next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Tue__12_Oct_2010_17_00_42_-0700_2=5bhSGCgEamaY.x
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 12 Oct 2010 19:33:11 -0400
Steve Wills <steve@mouf.net> mentioned:

>=20
> The rubygems.org page says it needs it, as does the metadata in the gem
> and the Rakefile.

But the library itself doesn't depend on hoe at all.
Look at the pkg-config.rb.

> I agree it's somewhat ugly, but it seems correct to me. I haven't found
> a warning for it in portlint, but maybe I'm not using the right flags
> (-abctCN)

`portlint -Ac` shows this.

>=20
> > 4. We usually prefer static pkg-plists instead of dynamic ones, especia=
lly
> >    in simple ones.  Although it's totally a maintainer consideration,
> >    it is usually nice to have a plist you can search in with grep.
>=20
> I agree it can be nice to be able to search. I just copied another
> rubygem-* port. Perhaps RUBYGEM_AUTOPLIST should be removed? I see 123
> other ports in ports/devel alone which use it.

Initially it was introduced for use in complex cases where plist can be
dynamical (e.g. when gem uses rdoc's you don't know files names beforehand).
Unfortunately some lazy/negligent maintainers found it easy to use and star=
ted
using it in the cases where you can live with the static plist.  Again,
it's the choice of the maintainer, it was just a suggestion how to make
the port a bit easier to work with.

>=20
> > 5. Although also a maintainer's choice I find it better to have
> >    non-gem versions of the libraries when they're available (like in
> >    this case).  The reasons are that the non-gem version can be used
> >    both in application that supports gems and the one that doesn't,
> >    and it is possible to patch the port when it is needed.  If in some
> >    time in future you will need to patch the contents on the port, it
> >    is impossible to do with gems.
>=20
> Sorry, I don't understand this. (Perhaps I should to be maintaining this
> port, but I don't.)
>=20

The essense of this paragraph was that gem libraries is not compatible with
applications that don't use gems explicitly.  So these application will need
to be patched to utilize gem's version of pkg-config.rb.  Essentially, non-=
gem
version is more universal.

--=20
Stanislav Sedov
ST4096-RIPE

--Signature=_Tue__12_Oct_2010_17_00_42_-0700_2=5bhSGCgEamaY.x
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJMtPauAAoJEL8lojEJL9nwr5YP/000ikOp+0XCHRRbClcRw0nT
qX1NIk8BznrSJDLDybRVpb1bf7vUWLaMLyXmLVcHcfCRnEGiwztrtht+sg/t4U6Z
RprAE9z+PaIdexsdW1GbxjUnxJJcPO1uAqnRluW7uXyAOd0tLsxDVLdtDg4qiXwC
Squ4SAZPpnJnO0bM8G+1ldiq9KIvs3hZpLAkXGrXTAOkmCtuzSGnrM48i15ywYzA
rrToD4QWe7yUuzr94BFfh61lBXZvYIb9nnpKJNmDeWnIomfeYySpr1r6TrpA0fqq
iH5tyc4TSu7O83eaHWPK4ZFDBKu7Cogt6tT2+irAs1NdiRSlkX2y3INiksMSTPNz
r/2OGRy4nkhmcDQEUkNZGWKZY8UW2q5MOsrXsagrOPgE77trM6Uqbx9OnjpyqxdG
h0dw9L5XWgxWYIcKOCVm2Oa5nRgV4C0tJJpvnyonjepizLxzJkr+P7T5D75U3QLC
0WERzC6YFCbqE3UpaRiY7EGQlfdbo/lZWD0wrP8YyJxQ5a5TC0gBBGmryhtcOfMx
AVT7CfZOUaZV7u2fvzP1TF1/+9exKcNdLZ/9hMu90TyFhWtnwveKpaXCrKRFy+AQ
5XA3ectOaUe5yPoeVTjuredWzkb1Z9aKY5UmRyoahr9aKX6QOKFRCnJd9RACBhpu
PTDkjWEX4PW1pxOZTJZX
=alPk
-----END PGP SIGNATURE-----

--Signature=_Tue__12_Oct_2010_17_00_42_-0700_2=5bhSGCgEamaY.x--



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