#2505 closed task (fixed)
Popt-1.14
| Reported by: | Owned by: | thomas | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | BOOK | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
New version of popt. Also, upstream has been moved to rpm5.org for a while, so that should be reflected in the book.
I'd like to get this in the book for 6.3. I've been using 1.13 for a while (1.14 just came out today).
Change History (9)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
| Milestone: | 6.3 → 7.0 |
|---|
Yeah, I agree. I don't think this needs to go in. I will probably change the tarball reference to rpm5.org, though.
comment:3 by , 16 years ago
| Milestone: | 7.0 → future |
|---|
comment:4 by , 16 years ago
For what is that sed in first line of the build instructions good for? The new version (1.14) has more that just one occurences of "*orgOptString ==" in popt.c. So it seems to me that we cannot simply drop in the new version.
comment:5 by , 16 years ago
I built 1.14 yesterday, using the cblfs instructions for non-multilib. So, removed that sed, but added seds to force libdir=/usr/lib in libpopt.la and .libs/libpopt.lai - no idea if those are needed in a straight LFS build (in the past, popt has made heroic assumptions about /lib64 directories on pure64, but for the moment BLFS only supports 32-bit). But either way, the current sed doesn't seem to be needed.
comment:6 by , 16 years ago
| Milestone: | future → 6.4 |
|---|
comment:7 by , 15 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:8 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Not sure why this needs to go in for 6.3 as what the book has now works for all applications that require it already. I've been sort of waiting for the existing tickets to get taken care of so we can get a release candidate going.
Piling on new package updates just slows the process. Your call, Dan, but sooner or later we have to draw the line and say "let's go with what we have".
The Rsync update is different to me in that it is a single application that relies on nothing, and nothing relies on it.
If you can get it in (you already have three tickets slated for 6.3) and you are 100% confident that it is a total drop-in replacement that won't affect any of the existing packages in the book (some of which are getting quite old), then great. If there is any doubt however, it doesn't make any sense to update something that we know works as it stands.