Let me start by adding a couple attachments:  current out-of-date-update.py and 
a faac..log.

The key element is that I am doing something like make clear=all repackage 
install and yet out-of-date c56.0->c57.0 faac message do not clear.  Looking at 
the log, I have the idea that I really need to remove a faac-1.26 file of some 
sort from pobj.  So I can do that, but I wonder if there is some magic make 
incantation that will do better by me.  Also, if a rm on a pobj file is needed, 
this circumstances seems to me to be unfortunate.

Thank you for your consideration.






________________________________
From: Stuart Henderson <[email protected]>
To: viq <[email protected]>; [email protected]
Cc: Max Stalnaker <[email protected]>
Sent: Fri, October 8, 2010 2:09:05 PM
Subject: Re: understanding out-of-date in infrastructure behavior

On 2010/10/08 18:15, viq wrote:
> On Fri, Oct 08, 2010 at 07:09:01AM -0700, Max Stalnaker wrote:
> > thanks for your response.  libc is more meaniful to me than c.56.0!
> > 
> > Now  it is true that I had done even a make all on faac using current  a 
> > few  
>
> > days ago.  I would have hoped that would clear dependency problems like  
>this.  
>

"make all" just builds the port. "make package" builds a package from it
providing one doesn't already exist. "make repackage" cleans any
existing packages of the same name and builds new ones.

> > On the other hand, looking at all the audio/faac files, I just  do not see 
>where 
>
> > they are version sensitive to this, at least when I  looked before I knew 
> > to 

> > look for libc stuff.

Let's say you have libfoo.so.1.0, which links against libc.so.56.0, and a
program foobar which is linked against libfoo.so.1.0 and libc.so.57.0.
When you try and run foobar you have a conflict because you can't have
both incompatible versions of libc in the same process space. This is
why when libraries are bumped you need to update many packages at once.

> > Now,  libc is not something that can be reasonable found with make search  
> > key=libc, but find / -name "libc" does okay and I see a devel port with  an 
> > unexpected name which I proceeded to build.  make clean package  install.

We have "make clean=all" now, this also removes packages, or you can
"make repackage".

> > Hmm, maybe I overwrote a good *system*  libc by doing this?

Packages do not overwrite system files.

> > Now I then run out-of-date-update.py a couple of times and what I get is 
>still 
>
> > faac  #c.56.0->c.57.0.
> > And  it is easy at this point to see many many ports with the same sole  
>issue 
>
> > as far as build/out-of-date would be concerned.  And my update  just does a 
> > clean and skips the rest of the make targets.
> > 
> > so "faac should be rebuilt/updated", but what this means at this point is 
> > unclear to me.
> > 
> > Please advise.
> 
> libc is in base system, ports don't affect it.
> 'make repackage' is what you are looking for in this case.
> I was thinking myself of a script that would delete all existing built
> packages of what is listed by out-of-date, but did not look at that yet.

viq, make SUBDIRLIST=/tmp/outofdate clean=package (or clean=all) would
probably do the trick for you here.


      

Attachment: out-of-date-update.py
Description: Binary data

Attachment: faac-1.26.log
Description: Binary data

Reply via email to