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

[ANDY KENNEDY]

> -----Original Message-----
> From: Yann E. MORIN [mailto:yann.morin.1998@anciens.enib.fr]
> Sent: Thursday, March 03, 2011 12:53 PM
> To: crossgcc@sourceware.org
> Cc: ANDY KENNEDY
> 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
so
> > 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
assures
> > that when we recheck to see if anything has changed, only
directories
> > that
> > have been modified will have a variant of the timestamp by at least
one
> > minute.
> 
> OK, my bad, sorry... I see the point, now.
> 
> Anyway, instead of trying to cover all cases, and coming up with
complex,
> 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
that
it was an issue of the unpacks unpack into other directories besides
their
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
known
> > 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
you
> > 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)
but
> > 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
that
> > we are getting from our code repo.  I make the offensive (usually
third
> > 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
intermediary
> 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:
${CT_SRC_DIR}/glibc/{all,glibc,files,here}
             /gcc/{all,gcc,files,here}

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
only
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
directories.
> 
> and we then would 'just' have to chmod the intermediary directory. Why
not.
> 
> 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
etc.

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.

Andy

--
For unsubscribe information see http://sourceware.org/lists.html#faq