devel/gettext notification in /usr/ports/UPDATING

[Matthew Seaman]

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, so 
>>> 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 single 
>>> one of
>>> the 173 ports depending on gettext needs to be rebuild because of libintl.
>> Great, all ports depending on devel/gettext got bumped.
>>
>> My Shell script checks every single library and executable on the system
>> with ldd and it says _nothing is amiss_ after upgrading devel/gettext.
> 
> And how does it know that all the existing libraries and executables are
> 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 

   (member of ldso_shared_object virtual category)

Hmmm... incidentally, that would also pretty much neatly define 
'architecture independent' vs 'architecture dependent' ports/packages[*], 
which could be parlayed into a useful saving of time on the package build 
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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20080607/7597922c/signature.pgp