Opened 18 years ago

Closed 17 years ago

#2028 closed task (fixed)

XFSProgs-2.8.18-1

Reported by: Randy McMurchy Owned by: alexander@…
Priority: normal Milestone: 6.2.0
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

Version increment to 2.8.4

http://oss.sgi.com/projects/xfs/

Change History (17)

comment:1 by cstgnr, 18 years ago

In this package you need to specific the owner and the group of the files that will be installed. This can be done setting the variables INSTALL_USER and INSTALL_GROUP. For example this can be done running make like this:

make DEBUG=-DNDEBUG INSTALL_USER=root INSTALL_GROUP=root

comment:2 by cstgnr, 18 years ago

To have a full installation of the xfsprogs package you should run as root this commands:

make install && make install-dev

comment:3 by Moody, 18 years ago

Version increment 2.8.11-1

comment:4 by djensen@…, 18 years ago

This seems to work well for 2.8.11-1

make DEBUG=-DNDEBUG INSTALL_USER=root INSTALL_GROUP=root &&
make install &&
make install-dev &&
chmod -v 755 /lib/libhandle.so*

except 3 installed symlinks to /usr/lib in /lib: libhandle.a, libhandle.la and libhandle.so should not be needed, and should be suppressed or deleted. I'll try to suppress them and commit this soon.

comment:5 by dnicholson@…, 18 years ago

I'd noticed, too, that there were some extra symlinks installed in /usr/lib and /lib. It should be one or the other. Possibly /lib since you might want your file system utilities accessible if /usr isn't mounted yet.

Regardless, the way I'd been thinking about it to leave out the make install-dev and recreating the installation by running the libtool commands directly. But if you've got a plan and want to take the bug, go for it. You could certainly let it do what it wants and then move the library around. You may also want to look into passing the PKG_DOC_DIR variable during the install to get /usr/share/doc/xfs-$VERSION rather than /usr/share/doc/xfs.

BTW, is there an install-lib target? There is one for the acl and attr packages that are packaged the same way.I can't recall what it does, but this is the way I'd installed acl (with a DESTDIR):

make DEBUG=-DNDEBUG OPTIMIZER="$CFLAGS"
make prefix=${PM_DEST}/usr \
	PKG_LIB_DIR=${PM_DEST}/lib \
	PKG_DEVLIB_DIR=${PM_DEST}/usr/lib \
	PKG_DOC_DIR=${PM_DEST}/usr/share/doc/acl-${VERSION} \
	install install-dev install-lib
rm -vf ${PM_DEST}/lib/libacl.{a,la,so}
ln -svf ../../lib/libacl.so.${SOVERSION} ${PM_DEST}/usr/lib/libacl.so

comment:6 by dnicholson@…, 18 years ago

I said two totally different things there. I don't know where the "doing libtool manually" stuff came from. What I would do if I was updating the package is the same thing I did for acl minus all the PM_DEST stuff.

comment:7 by djensen@…, 18 years ago

The .a and .la are only needed for building and should never be needed in /lib. Those and the .so, being links won't help at boot anyway. Let's give em the boot.

I didn't notice the doc dir shortcoming. Looking at what they install, I'm tempted to give the doc install the boot too. There is nothing there of interest unless you are working with the source, at which time you have these files where you need them, in the source.

comment:8 by Randy McMurchy, 18 years ago

Summary: XFSProgs-2.8.4XFSProgs-2.8.11-1

comment:9 by djensen@…, 18 years ago

After messing with this for two weeks, I don't have a plan! Make builds libxcmd.{so,a}, libxlog.{so,a}, libxfs.{so,a}, libdisk.{so,a} and libhandle.{so,a}. Make install only installs libhandle.so.version. Make install-dev installs the headers all the .a's but only libhandle.la and no more .so's, I don't understand their intentions or plans.

I ldd'd the binaries, they dont link to libhandle.so, maybe dlopened? This is over my head! Perhaps keep current instructions and leave the install-dev till we get some input.

comment:10 by Randy McMurchy, 17 years ago

Milestone: 6.2.06.2.1

comment:11 by alexander@…, 17 years ago

Sorry, I disagree with the change of milestone. The current link in the book is dead. The instructions are wrong for the 2.8.18-1 version from the security standpoint (rpath contains the builder's home directory). So either give me the task of updating the package, or drop it from the book.

comment:12 by alexander@…, 17 years ago

Keywords: security maybe-remove added
Milestone: 6.2.16.2.0
Severity: normalblocker

comment:13 by alexander@…, 17 years ago

Summary: XFSProgs-2.8.11-1XFSProgs-2.8.18-1

comment:14 by Randy McMurchy, 17 years ago

It is not a matter of "giving you the task of updating the package", it is a matter of you accepting the bug and fixing it.

From here on out, if you are so confident that a package is so wrong that unless it is fixed it probably should be removed, then simply fix it. Period.

If you feel it is necessary, send a message to BLFS-Dev and wait a day or so, but you've been invited (and now being counted on) to fix what you see is wrong.

Jump in, Alexander. Do what you think is right. You have everyone's confidence and support. You don't need to ask permission to make changes you know to be right.

comment:15 by alexander@…, 17 years ago

Owner: changed from blfs-book@… to alexander@…

Accepting the update

comment:16 by alexander@…, 17 years ago

Keywords: security maybe-remove removed
Severity: blockernormal

Sorry for the FUD. The rpath issue is a LiveCD-specific libtool issue (I should not allow config.site to disable static library support in libtool).

comment:17 by alexander@…, 17 years ago

Resolution: fixed
Status: newclosed

Fixed in r6389, explained the difference between the full and non-dev installations.

Non-installation of *.so is intentional. The XFS programs link to libhandle.a statically. libhandle.so seems to be unused.

Note: See TracTickets for help on using tickets.