[Top] [All Lists]

Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification ...

To: b.j.smith@xxxxxxxx, thebs@xxxxxxxxxxx
Subject: Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification ...
From: Nathan Scott <nathans@xxxxxxx>
Date: Mon, 26 Feb 2001 07:54:34 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <3A994CF2.6FB00D8F@xxxxxxxx>; from b.j.smith@xxxxxxxx on Sun, Feb 25, 2001 at 01:20:34PM -0500
References: <3A947AA9.F12C2572@xxxxxxxxxxxxx> <3A947A20.6E79C8BF@xxxxxxx> <3A98B6FE.1E056F6B@xxxxxxxxxxxxx> <news2mail-97afe0$52i$1@xxxxxxxxxxxxxxxxxxxxxx> <3A9948DB.993500E2@xxxxxxxxxxxxx> <news2mail-97bgbh$on6$1@xxxxxxxxxxxxxxxxxxxxxx> <3A994CF2.6FB00D8F@xxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx

On Sun, Feb 25, 2001 at 01:20:34PM -0500, Bryan J. Smith wrote:
> Re: libxfs.h and the xfsprogs-devel package? <- Er, clarification
> ...
> No, I'm familiar with that.  I already built:
>    acl-1.0.1-0.i386.rpm
>    acl-devel-1.0.1-0.i386.rpm
>    attr-1.0.1-0.i386.rpm
>    attr-devel-1.0.1-0.i386.rpm
>    dmapi-0.1.1-0.i386.rpm
>    dmapi-devel-0.1.1-0.i386.rpm
>    xfsdump-1.0.2-0.i386.rpm
>    xfsprogs-1.1.2-0.i386.rpm
>    xfsprogs-devel-1.1.2-0.i386.rpm
> What I was talking about was building _unified_ RPM akin to
> "xfs-cmds-1.0.5-1.i386.rpm" like in Pre-Release 0.9.  That way I
> don't have to modify Anaconda to know that all those RPMs replace
> that one.

These RPMs don't replace that one - there has never been acl and
dmapi code in a released package so far, for example, and there
were a few other changes at the same time such that this is not
a true upgrade but a complete repackaging.

Packages like the acl ones (which currently only works for xfs) may
disappear entirely once a system call has been finalized (at which 
point we'll be likely to pick up the acl.bestbits.at packages and
replace the current ones with those).

The attr packages are in a similar boat - they rely on a custom
syscall interface which will change, so we don't want any of the
base tools (xfsprogs) to be affected by upheaval in that area.
The xfsdump package depends on this attr package as well, so it
is no longer part of the base xfsprogs set.

And of course, the extended attribute and acl interfaces are not
going to be xfs-specific forever, so leaving those tools in with
the other xfs-specific ones is the wrong thing to do.

And finally, by having smaller focused packages, people can
download and install only those components that they need/want.
So, there were a number of very good reasons for doing this, but
the upshot is the unified xfs-cmds package is history.

> As such, I just suggested putting a .spec file in the "cmd" CVS root
> so you can.  I tried merging spec/makefiles in an attempt to create
> a new "xfs-cmds-*.i386.rpm" to no avail.

I think you're taking the wrong approach - there wont be any more
xfs-cmds packages coming out of sgi, so moving forward its best to
track the new packaging scheme.  Unfortunately, I didn't have this
all working in the 0.9 (beta) timeframe, so we had to leave it for
a future release.

Hope this helps.



<Prev in Thread] Current Thread [Next in Thread>