chmod -R u+w .build/src EACH TIME?????

Thu Mar 3 19:34:00 GMT 2011

> -----Original Message-----
> From: Yann E. MORIN []
> Sent: Thursday, March 03, 2011 12:53 PM
> To:
> Subject: Re: chmod -R u+w .build/src EACH TIME?????
> Andy, All,
> On Thursday 03 March 2011 19:27:39 ANDY KENNEDY wrote:
> > You didn't understand the point of the one minute offset.  This was
> > that
> > all directories in the CWD would hold the same time as an arbitrary
> > known unmodified point.  To set the touch one minute in the past
> > that when we recheck to see if anything has changed, only
> > that
> > have been modified will have a variant of the timestamp by at least
> > minute.
> OK, my bad, sorry... I see the point, now.
> Anyway, instead of trying to cover all cases, and coming up with
> flawed heuristics, I decided to reap this big chmod away, and have
> offending packages cleanup the mess behind them. The culprits are:
> - autoconf-2.65
> - automake-1.11.1
> - libtool-2.2.6b
> - make-3.81
> - ncurses-5.7, all files
> Onlt five of them. It took only a few minutes to do a chmod in all
> 5 of them, so no big deal...

I'm confused.  I must really be misreading what you wrote.  I thought
it was an issue of the unpacks unpack into other directories besides
own?  Like autoconf-2.65 unpacks into automake a subdirectory/files to
identify autoconf-2.65.  I must really have read into what you wrote.

> > See, we take the Doc's Delorean, hit 88MPH and go back in time
> > precisely one minute.
> Hehe... 88MPH.. Hehe! :-)

Sorry, I really enjoyed the 80s.

> > I don't really understand why you are not allowed to extract into
> > source directories?  If it is due to the fact that some tarballs you
> > extract are overwriting dirs that are expected to be in CWD, could
> > not contain all of the offending dirs into a single dir -- yes, you
> > would
> > have to reach out a bit deeper to get to the offending Makefile(s)
> > you could then control the names of the extract directories.  All in
> > all,
> > it would make the scripts easier to write (I would think).
> >
> > This is, in fact, what I'm doing in BuildRoot for proprietary code
> > we are getting from our code repo.  I make the offensive (usually
> > party) code be one level deep and I supply a Makefile that preps the
> > build another level deep.
> OK, so you mean every tarball should be extracted into its own
> directory, so we'd get:
>   ${CT_SRC_DIR}/glibc/glibc-2.9/{all,glibc,files,here}
>                /gcc/gcc-4.3.2/{all,gcc,files,here}

No, it would be:

for these cases as the --strip-components n removes n number of leading
parent dirs. I think you can do just --strip-components <no arg> and
get one dir stripped.

Though, if you have offensive tarballs as the ones I originally thought
you were talking about, then yes, you'd have an additional level of
> and we then would 'just' have to chmod the intermediary directory. Why
> But the per-package chmod is far easier to handle, so far!

You would 'just' have to do a chmod of the package after the unpack:

chmod -R u+w ${CT_SRC_DIR}/${pkg_name}

where in our above examples would be:

chmod -R u+w ${CT_SRC_DIR}/gcc
chmod -R u+w ${CT_SRC_DIR}/glibc

Which seems much less complicated to me.  No need to poll the FS
just to find the name of the package dir either. . .

Though, if that seems foreign to you and you don't like it (and this is
ultimately your project) you have the final say.


For unsubscribe information see

More information about the crossgcc mailing list