On 2/27/2013 11:23 PM, JonY wrote:
On 2/27/2013 21:59, Corinna Vinschen wrote:
On Feb 27 21:29, JonY wrote:
On 2/27/2013 21:10, Corinna Vinschen wrote
Just upload the test release to the release area and write a TEST mail
to cygwin-announce. Or is there anything special you'd like to do?
I'm worried that I might break gcc installs if I overlooked something
obvious.
The upload will be overwriting the .hint files, java and libffi are
empty packages (I could not get java to build yet).
I'm not concerend about java (dum di dum), but why is libffi missing?
libffi only gets built when Java is enabled.
I can't figure out
how to pack the debuginfo package, it is always empty.
Yaakov might be able to help here.
Hi Yaakov, I have gcc4_debuginfo_CONTENTS="usr/lib/debug/" in the
cygport file, any ideas?
Will you be able to rollback my uploads in case something does go wrong?
In theory, yes. If you leave the dependencies in place for the "curr"
release, then the test release shouldn't interfere and testers will
have to care for the stuff themselves. Let's assume for a start, that
downmloaders of a gcc test package know what they are doing.
Now this brings up a good question. libgnat4.5 became libgnat4.7 in
4.7.2, likewise for libobjc2 to libobjc4. So you are saying that I
should leave the runtime depends for 4.5.x?
yes, otherwise you break it for current
Put the test depends in the test announcement, so who want to test
will add by hand.
http://cygwin.com/ml/cygwin-apps/2012-11/msg00067.html
Another way to distinguish the new gcc from the current on would be
perhaps to create a "gcc472" package set, distinct from the other gcc
packages. It could install itself into /usr/local, just for the test
period.
Yeah, I know, I know, no official package should install into
/usr/local. Maybe /opt would be fine for once, too.
That might be a saner approach to testing. Do I need to use postinstall
to add it to PATH? If so, how do I do that?
looks at:
/etc/profile.d/lapack0.csh
/etc/profile.d/lapack0.sh
Marco
