MacPorts v1.4.2 released

[David Liontooth]

James Berry wrote:
> Hi David,
>
> On Apr 17, 2007, at 9:47 AM, David Liontooth wrote:
>
>> Emmanuel Hainry wrote:
>>> Citando Ryan Schmidt :
>>>
>>>> Perhaps you meant to clean only the *installed* ports. But I'm still
>>>> not clear why. I think MacPorts automatically cleans each port after
>>>> it's installed, so you really shouldn't need to clean the installed
>>>> ports.
>>>>
>>>
>>> port automatically cleans the work (build) directory, but not the
>>> distfiles and the archives, which port clean --all does. So it is a way
>>> to gain some disk files as distfiles can begin to pile up if there are
>>> frequent updates. Uninstalling inactive ports frees a lot of room too.
>>>
>> Wouldn't it be useful in that case to have the "port clean --all"
>> command tolerate a failed request to clean a package that's not
>> available?
>>
>> $ sudo port -f clean --all all
>> --->  Cleaning ngrep
>> nhc98 is not supported on OS X i386 yet
>>
>> It's not a critical discovery that nhc98 is not yet supported; the
>> script should just move on.
>
> I'll certainly agree that the nhc98 port is misbehaving in this case.
> It should make such a complaint on destroot or configure, or
> something, but not when the portfile is opened.
>
> I believe that if you pass the -p flag to port, that this error (and
> any others) in a particular port will be ignored. The -p flag
> basically says that, while processing multiple ports (such as those
> furnished by all) that an error in one should be ignored.
Hi James,

I just upgraded to your hot-off-the-stove 1.4.3 flawlessly, and then tried

     sudo port -f clean -p --all all

It stumbled here:

    Error: Unable to open port: couldn't change working directory to
    "/opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/x11/gtk26":
    no such file or directory

The gtk26 maintainer just requested the package be removed, and Maun
Suang reported, "Done in r24129." I found
/opt/local/etc/ports/sources.conf, where it seems port is downloading a
fresh list -- what's the design feature that throws up this disagreement?

This time I created a fake directory and portfile and got past that
point, only to stumble again on the same package as when I was not using
the -p flag:

    nhc98 is not supported on OS X i386 yet

I would much prefer you were correct that the -p flag would inspire port
to take such troubles in its stride, but alas, it fell on its face again.

Cheers,
Dave