I'm trying to put together an SRPM that will pass review for the
Fedora Extras crowd. So I have a two questions and a comment, and
I'll start with the most trivial:
- the main page has a broken link -- the third bullet under the
Debian GNU/Linux download section (the "tar-ball") has an extra
"-1" in its name -- it ought to be: http://nco.sourceforge.net/src/nco_3.0.0.tar.gz
With that biggie out of the way [;-)], I'd like to suggest adding the
following line to src/nco/Makefile.am:
include_HEADERS = $(HEADER_SRC)
so that the C headers will be installed along with the C++ headers.
Is that OK?
And finally, would it be possible to change the shared library name
like this:
I realize that the shared-library name change implies that the NCO
shared libraries are, in some sense, becoming more "stable". And I
can totally appreciate why you wouldn't want to make such a change.
You may have excellent reasons to think that your libraries are very
likely to change (perhaps drastically) between each release.
It just seems (from my ignorant position!) that NCO libraries have
been somewhat stable for the past few releases. So maybe changing the
"so-names" would be OK?
Thank you for your time!
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately that's not a typo---it's a feature!
The link to that file is broken because the Debian builds are broken
because the Debian netCDF maintainer is inactive and has not released
netCDF 3.6.0 debs.
> I'd like to suggest adding the
> following line to src/nco/Makefile.am:
>
> include_HEADERS = $(HEADER_SRC)
>
> so that the C headers will be installed along with the C++ headers.
> Is that OK?
Yup.
> I realize that the shared-library name change implies that the NCO
> shared libraries are, in some sense, becoming more "stable". And I
> can totally appreciate why you wouldn't want to make such a change.
> You may have excellent reasons to think that your libraries are very
> likely to change (perhaps drastically) between each release.
> It just seems (from my ignorant position!) that NCO libraries have
> been somewhat stable for the past few releases. So maybe changing the
> "so-names" would be OK?
The library API is changing slowly.
There is no overall plan to freeze the API.
Only NCO executables actually call the library.
3.0.1 will be slightly different than 3.0.0.
Hence the binary packages (RPM, deb) should definitely install the
3.0.1 library.
3.0.0 executables will not work with the 3.0.1 library, and visa versa.
If the Fedora policy prefers to symlink to the 3.0.1 library
through the libnco.so.3 name, that's fine with me.
Let Harry weigh in since he is working on cross-platform issues,
and he may be aware of other issues that would affect this decision.
If you two think it's a wise idea, then go ahead.
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And I'd like to withdraw my request to change your so-name scheme. Since you expect 3.0.1 to differ from 3.0.0, your current scheme is clearly better than the proposed change.
thanks again!
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Saturday 16 April 2005 10:50 pm, Charlie wrote:
> The library API is changing slowly.
> There is no overall plan to freeze the API.
> Only NCO executables actually call the library.
>
> 3.0.1 will be slightly different than 3.0.0.
> Hence the binary packages (RPM, deb) should definitely install the
> 3.0.1 library.
> 3.0.0 executables will not work with the 3.0.1 library, and visa versa.
> If the Fedora policy prefers to symlink to the 3.0.1 library
> through the libnco.so.3 name, that's fine with me.
> Let Harry weigh in since he is working on cross-platform issues,
> and he may be aware of other issues that would affect this decision.
> If you two think it's a wise idea, then go ahead.
Ed's changes are OK with me. The only problem I foresee is the "long symlink path" problem that seems to be the unavoidable (but logical) result of this kind of moving lib target. In my Debian /usr/lib dir, 262 of 405 libs are symlinks to the real file.
I don't know what the official protocol is for RedHat, but Ed's proposal seems fine as long as it doesn't mess up those rules.
--
Cheers, Harry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't understand that the shared library APIs were changing in basically every NCO release. In that case, the "so-name" change suggestion is not a good idea and I'd like to withdraw it. And my apologies for any time that I've wasted on this topic!
thanks,
Ed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One long term (maybe one year) idea is to turn some of libnco
into web-service-accessible calls. Then things like OPeNDAP could
send netCDF files as byte-streams to the service (at one end)
and receive (from the service) netCDF files as byte streams.
In order for this work reliably, we would need to freeze some APIs.
However, this is all hand-waving and requires an interested person to implement it. Let's talk again on how to name the libraries if/when we start to make progress on such tools.
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi folks,
I'm trying to put together an SRPM that will pass review for the
Fedora Extras crowd. So I have a two questions and a comment, and
I'll start with the most trivial:
- the main page has a broken link -- the third bullet under the
Debian GNU/Linux download section (the "tar-ball") has an extra
"-1" in its name -- it ought to be:
http://nco.sourceforge.net/src/nco_3.0.0.tar.gz
With that biggie out of the way [;-)], I'd like to suggest adding the
following line to src/nco/Makefile.am:
include_HEADERS = $(HEADER_SRC)
so that the C headers will be installed along with the C++ headers.
Is that OK?
And finally, would it be possible to change the shared library name
like this:
current:
libnco.so -> libnco-3.0.0.so
libnco-3.0.0.so
proposed:
libnco.so -> libnco.so.3
libnco.so.3 -> libnco.so.3.0.0
libnco.so.3.0.0
which would just involve changing the following two lines in two
files:
diff nco-3.0.0/src/nco/Makefile.am nco-3.0.0_new/src/nco/Makefile.am
70c70
< libnco_la_LDFLAGS = -release @VERSION@
---
> libnco_la_LDFLAGS = -version-info 3:0:0
diff nco-3.0.0/src/nco_c++/Makefile.am nco-3.0.0_new/src/nco_c++/Makefile.am
10c10
< libnco_c___la_LDFLAGS = -release @VERSION@
---
> libnco_c___la_LDFLAGS = -version-info 3:0:0
I realize that the shared-library name change implies that the NCO
shared libraries are, in some sense, becoming more "stable". And I
can totally appreciate why you wouldn't want to make such a change.
You may have excellent reasons to think that your libraries are very
likely to change (perhaps drastically) between each release.
It just seems (from my ignorant position!) that NCO libraries have
been somewhat stable for the past few releases. So maybe changing the
"so-names" would be OK?
Thank you for your time!
Ed
Ha! I also got the tar-ball link wrong, even as I was trying to suggest a correction. The "_" should be a "-". Please pardon my sloppiness!
Ed
Hi Ed,
> With that biggie out of the way [;-)],
Unfortunately that's not a typo---it's a feature!
The link to that file is broken because the Debian builds are broken
because the Debian netCDF maintainer is inactive and has not released
netCDF 3.6.0 debs.
> I'd like to suggest adding the
> following line to src/nco/Makefile.am:
>
> include_HEADERS = $(HEADER_SRC)
>
> so that the C headers will be installed along with the C++ headers.
> Is that OK?
Yup.
> I realize that the shared-library name change implies that the NCO
> shared libraries are, in some sense, becoming more "stable". And I
> can totally appreciate why you wouldn't want to make such a change.
> You may have excellent reasons to think that your libraries are very
> likely to change (perhaps drastically) between each release.
> It just seems (from my ignorant position!) that NCO libraries have
> been somewhat stable for the past few releases. So maybe changing the
> "so-names" would be OK?
The library API is changing slowly.
There is no overall plan to freeze the API.
Only NCO executables actually call the library.
3.0.1 will be slightly different than 3.0.0.
Hence the binary packages (RPM, deb) should definitely install the
3.0.1 library.
3.0.0 executables will not work with the 3.0.1 library, and visa versa.
If the Fedora policy prefers to symlink to the 3.0.1 library
through the libnco.so.3 name, that's fine with me.
Let Harry weigh in since he is working on cross-platform issues,
and he may be aware of other issues that would affect this decision.
If you two think it's a wise idea, then go ahead.
Thanks,
Charlie
Hi Charlie,
Thank you for the prompt response!
And I'd like to withdraw my request to change your so-name scheme. Since you expect 3.0.1 to differ from 3.0.0, your current scheme is clearly better than the proposed change.
thanks again!
Ed
On Saturday 16 April 2005 10:50 pm, Charlie wrote:
> The library API is changing slowly.
> There is no overall plan to freeze the API.
> Only NCO executables actually call the library.
>
> 3.0.1 will be slightly different than 3.0.0.
> Hence the binary packages (RPM, deb) should definitely install the
> 3.0.1 library.
> 3.0.0 executables will not work with the 3.0.1 library, and visa versa.
> If the Fedora policy prefers to symlink to the 3.0.1 library
> through the libnco.so.3 name, that's fine with me.
> Let Harry weigh in since he is working on cross-platform issues,
> and he may be aware of other issues that would affect this decision.
> If you two think it's a wise idea, then go ahead.
Ed's changes are OK with me. The only problem I foresee is the "long symlink path" problem that seems to be the unavoidable (but logical) result of this kind of moving lib target. In my Debian /usr/lib dir, 262 of 405 libs are symlinks to the real file.
I don't know what the official protocol is for RedHat, but Ed's proposal seems fine as long as it doesn't mess up those rules.
--
Cheers, Harry
Hi Harry,
I didn't understand that the shared library APIs were changing in basically every NCO release. In that case, the "so-name" change suggestion is not a good idea and I'd like to withdraw it. And my apologies for any time that I've wasted on this topic!
thanks,
Ed
Hi Ed and Harry,
One long term (maybe one year) idea is to turn some of libnco
into web-service-accessible calls. Then things like OPeNDAP could
send netCDF files as byte-streams to the service (at one end)
and receive (from the service) netCDF files as byte streams.
In order for this work reliably, we would need to freeze some APIs.
However, this is all hand-waving and requires an interested person to implement it. Let's talk again on how to name the libraries if/when we start to make progress on such tools.
Thanks,
Charlie