3:57 p.m.
Folks,
I have two quandaries about my OpenAFS packages. Both of which are a
bit problematic when trying to conform to the Fedora Packaging
Guidelines.
OpenAFS has a slew of static libraries that are part of upstream's
packages and used for just about anything that uses OpenAFS's C API,
such as the perl-AFS modules.
I've removed them from my packages here in rpmFusion because shipping
static libraries is against the Fedora package guidelines. Turns out
this is preventing a lot of stuff we have from being able to build in
our RHEL 6 and Fedora 14 environments.
Consulting
http://fedoraproject.org/wiki/PackagingGuidelines#Packaging_Static_Libraries
it looks like the proper thing to do is include these static libraries in
the -devel sub-package and have that sub-package provide openafs-static.
Secondly, many more experienced AFS administrators prefer the old
Transarc style paths over the FHS paths that my packages use. I would
like to create an openafs-transarc sub-package that includes the
symlinks that would enable these non-standard paths. (Specifically,
/usr/afs and /usr/vice.)
The first issue with the static libs really needs to happen. The second
issue is just pure annoyance but will make these packages more usable to
certain folks. I'd like to do both. Are there any comments or reason
why I should not?
Jack Neely
--
Jack Neely <jjneely(a)ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
4:08 p.m.
On 03/04/2011 04:57 PM, Jack Neely wrote:
Secondly, many more experienced AFS administrators prefer the old
Transarc style paths over the FHS paths that my packages use. I would
like to create an openafs-transarc sub-package that includes the
symlinks that would enable these non-standard paths. (Specifically,
/usr/afs and /usr/vice.)
No way, never.
The first issue with the static libs really needs to happen. The
second
issue is just pure annoyance but will make these packages more usable to
certain folks. I'd like to do both. Are there any comments or reason
why I should not?
Because this "transarc style" doesn't comply to the FHS.
Ralf
5:28 p.m.
On Fri, Mar 4, 2011 at 9:08 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
Because this "transarc style" doesn't comply to the FHS.
I think FHS is a good thing to have. Several packages have exceptions,
eg. krb5-workstation
$ rpm -ql krb5-workstation
/usr/kerberos
/usr/kerberos/bin
/usr/kerberos/bin/k5srvutil
/usr/kerberos/bin/kadmin
/usr/kerberos/bin/kdestroy
/usr/kerberos/bin/kinit
/usr/kerberos/bin/klist
...
Jack's simply proposing that this optional openafs-compat package
provide symlinks in the non-FHS locations. The main packages' binaries
would still follow the FHS.
- Ken
6:28 p.m.
On Fri, Mar 04, 2011 at 10:28:44AM -0700, Ken Dreyer wrote:
On Fri, Mar 4, 2011 at 9:08 AM, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
>
> Because this "transarc style" doesn't comply to the FHS.
I think FHS is a good thing to have. Several packages have exceptions,
eg. krb5-workstation
$ rpm -ql krb5-workstation
/usr/kerberos
/usr/kerberos/bin
/usr/kerberos/bin/k5srvutil
/usr/kerberos/bin/kadmin
/usr/kerberos/bin/kdestroy
/usr/kerberos/bin/kinit
/usr/kerberos/bin/klist
...
Jack's simply proposing that this optional openafs-compat package
provide symlinks in the non-FHS locations. The main packages' binaries
would still follow the FHS.
- Ken
And even krb5-workstation has been fixed to comply with the FHS in most
recent Fedoras and RHEL 6. I do believe the FHS is the right way, but I've
gotten enough feedback to think that this compat package of symlinks to
the FHS locations is worth considering.
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
6:35 p.m.
On 03/04/2011 06:28 PM, Ken Dreyer wrote:
On Fri, Mar 4, 2011 at 9:08 AM, Ralf
Corsepius<rc040203(a)freenet.de> wrote:
>
> Because this "transarc style" doesn't comply to the FHS.
I think FHS is a good thing to have. Several packages have exceptions,
They don't have an exception, they are broken rsp. certain people @RH
are ignoring the FHS.
Ralf
2:45 a.m.
On Fri, 4 Mar 2011 10:57:35 -0500
Jack Neely <jjneely(a)ncsu.edu> wrote:
it looks like the proper thing to do is include these
static libraries in the -devel sub-package and have that
sub-package provide openafs-static.
Secondly, many more experienced AFS administrators prefer
the old Transarc style paths over the FHS paths that my
packages use. I would like to create an openafs-transarc
sub-package that includes the symlinks that would enable
these non-standard paths. (Specifically, /usr/afs
and /usr/vice.)
The first issue with the static libs really needs to
happen. The second issue is just pure annoyance but will
make these packages more usable to certain folks. I'd like
to do both. Are there any comments or reason why I should
not?
Jack Neely
Both sound good to me (yes, the FHS is a nice ideal, but a
compat package with "DEPRECATED" somewhere in the description
is an ok crutch). And as Ralf has so helpfully pointed out,
not even RH follows the FHS 100%.
--
Conrad Meyer <cemeyer(a)cs.washington.edu>
4 p.m.
On Sat, Mar 05, 2011 at 06:45:37PM -0800, Conrad Meyer wrote:
On Fri, 4 Mar 2011 10:57:35 -0500
Jack Neely <jjneely(a)ncsu.edu> wrote:
> it looks like the proper thing to do is include these
> static libraries in the -devel sub-package and have that
> sub-package provide openafs-static.
>
> Secondly, many more experienced AFS administrators prefer
> the old Transarc style paths over the FHS paths that my
> packages use. I would like to create an openafs-transarc
> sub-package that includes the symlinks that would enable
> these non-standard paths. (Specifically, /usr/afs
> and /usr/vice.)
>
> The first issue with the static libs really needs to
> happen. The second issue is just pure annoyance but will
> make these packages more usable to certain folks. I'd like
> to do both. Are there any comments or reason why I should
> not?
>
> Jack Neely
Both sound good to me (yes, the FHS is a nice ideal, but a
compat package with "DEPRECATED" somewhere in the description
is an ok crutch). And as Ralf has so helpfully pointed out,
not even RH follows the FHS 100%.
--
Conrad Meyer <cemeyer(a)cs.washington.edu>
So at this point I will definitely include the static libraries.
(Provided I can get them compiled with -fPIC so perl-AFS builds on
x86_64. *grumble*) Which means I might contribute perl-AFS in the
future.
For the Transarc paths, would folks like an openafs-compat package
rather than openafs-transarc? (Transarc is the company Carnegie Mellon
spun off to commercially develop AFS before it was bought by IBM and
released as Open Source.)
Any news on the build system?
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
4793
days inactive
4796
days old
rpmfusion-developers@lists.rpmfusion.org
6 comments
4 participants
participants (4)
-
Conrad Meyer -
Jack Neely -
Ken Dreyer -
Ralf Corsepius