Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Jun 2008 08:55:42 +0100
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Erik Trulsson <ertr1013@student.uu.se>
Cc:        Dominic Fandrey <kamikaze@bsdforen.de>, freebsd-ports@freebsd.org
Subject:   Re: devel/gettext notification in /usr/ports/UPDATING
Message-ID:  <484A3EFE.9080100@infracaninophile.co.uk>
In-Reply-To: <20080606173649.GA88328@owl.midgard.homeip.net>
References:  <484945CA.3010305@bsdforen.de> <4849681B.6070002@bsdforen.de> <20080606173649.GA88328@owl.midgard.homeip.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig21ADB6638AEDCC9F3C4FCB8E
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Erik Trulsson wrote:
> On Fri, Jun 06, 2008 at 06:38:51PM +0200, Dominic Fandrey wrote:
>> Dominic Fandrey wrote:

>>> I have 761 ports installed, but only 173 of them depend on gettext, s=
o=20
>>> why should
>>> I reinstall more than 530 ports that don't need to be rebuild.
>>>
>>> What's even worse according to my shell-script pkg_libchk not a singl=
e=20
>>> one of
>>> the 173 ports depending on gettext needs to be rebuild because of lib=
intl.
>> Great, all ports depending on devel/gettext got bumped.
>>
>> My Shell script checks every single library and executable on the syst=
em
>> with ldd and it says _nothing is amiss_ after upgrading devel/gettext.=

>=20
> And how does it know that all the existing libraries and executables ar=
e
> completely compatible with the new devel/gettext?

Freshports informed me overnight that four of the ports I maintain
had a revision bump because of this getext update -- and it is true
that they are all ports where gettext appears as a run-dependency
in the INDEX. However, look at the ports in question:

   databases/mysql-connector-java
   databases/mysql-connector-java50
   net/phpldapadmin
   net/phpldapadmin098

They're all either interpreted language code or byte-compiled code
-- none of which knows anything at all about the ABI versions of the
gettext shlibs and have only inherited the run-depends from their
parent applications (php, java) which are compiled C or C++ code.

I suspect that the majority of the 5007 ports flagged for portrevision
bump for having the run-depends probably fall into this category.

Currently there is no simple way to distinguish between dependent
ports that would be affected by this sort of shlib ABI change and
ones that wouldn't.

One idea might be to add a new virtual category: ldso_shared_object
for anything that directly requires ld.so(1) functionality.  ie. so
shell scripts, kernel modules, pear modules, native java code and
pure perl etc. won't be members of that category, but compiled C/C++,
apache modules, pecl, JNI, perl XS would.

In this case, the test for needing a portrevision bump would be:

   (run-depends on gettext)

   AND=20

   (member of ldso_shared_object virtual category)

Hmmm... incidentally, that would also pretty much neatly define=20
'architecture independent' vs 'architecture dependent' ports/packages[*],=
=20
which could be parlayed into a useful saving of time on the package build=
=20
cluster and of space on the FTP servers.

Now, to survey 18,500 ports and decide what category each should be
in....  not a small undertaking.  I'm happy to put my money where my
mouth is and work on that if the consensus is that this would be a
worthwhile thing.

	Cheers,

	Matthew

[*] Well, except for anything that is statically linked native compiled
code (is there anything like that in ports?) or kernel modules or similar=
=2E

--=20
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW


--------------enig21ADB6638AEDCC9F3C4FCB8E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkhKPwUACgkQ8Mjk52CukIwdygCdEX6svLtvXlrlqEjHEp2FxYKN
JDQAn3be1aldf7RG1l5q2wOmf5wSl5yO
=E/HS
-----END PGP SIGNATURE-----

--------------enig21ADB6638AEDCC9F3C4FCB8E--



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