9:14 a.m.
The Fedora fuse package currently builds rpms called fuse/fuse-libs and
fuse3/fuse3-libs, the former for fuse-2 versions and the latter for
fuse-3. The community I support has a need for fuse3/fuse3-libs on
EPEL, so I would like to backport them from Fedora to EPEL. Does anyone
have an objection to this? I plan to make a pagure issue on it for
EPSCO review.
The need for this is to take advantage of a feature beginning in
libfuse-3.3.0 that enables pre-mounting fuse filesystems.
https://github.com/libfuse/libfuse/releases/tag/fuse-3.3.0
We want to add an option to singularity to pre-mount fuse and then run
the fuse filesystem code inside of el6 & el7 containers, in particular
the CernVM FileSystem which is based on fuse.
https://github.com/cvmfs/cvmfs
The package maintainer is cooperating with me on this
https://bugzilla.redhat.com/show_bug.cgi?id=1696454
Since RHEL already includes fuse/fuse-libs rpms, my intention is to
update the .spec file so those will not build on el6 & 7, leaving only
fuse3/fuse3-libs. On the other hand, I'm not sure rpmbuild will be
happy with having a fuse.spec that does not generate a fuse rpm, I will
try it. I guess the alternative would be to split fuse3 out into a
separate pagure/bodhi/koji package but it would be good to avoid that.
Dave
10:04 a.m.
On Fri, 5 Apr 2019 at 10:14, David Dykstra <dwd(a)fnal.gov> wrote:
The Fedora fuse package currently builds rpms called fuse/fuse-libs and
fuse3/fuse3-libs, the former for fuse-2 versions and the latter for
fuse-3. The community I support has a need for fuse3/fuse3-libs on
EPEL, so I would like to backport them from Fedora to EPEL. Does anyone
have an objection to this? I plan to make a pagure issue on it for
EPSCO review.
The need for this is to take advantage of a feature beginning in
libfuse-3.3.0 that enables pre-mounting fuse filesystems.
https://github.com/libfuse/libfuse/releases/tag/fuse-3.3.0
We want to add an option to singularity to pre-mount fuse and then run
the fuse filesystem code inside of el6 & el7 containers, in particular
the CernVM FileSystem which is based on fuse.
https://github.com/cvmfs/cvmfs
The package maintainer is cooperating with me on this
https://bugzilla.redhat.com/show_bug.cgi?id=1696454
Since RHEL already includes fuse/fuse-libs rpms, my intention is to
update the .spec file so those will not build on el6 & 7, leaving only
fuse3/fuse3-libs. On the other hand, I'm not sure rpmbuild will be
happy with having a fuse.spec that does not generate a fuse rpm, I will
try it. I guess the alternative would be to split fuse3 out into a
separate pagure/bodhi/koji package but it would be good to avoid that.
I believe that you need to rename the src.rpm spec to being fuse3 for
this to work with koji. Even though your package is not building fuse2
items, koji uses the src.rpm and will see yours as being newer than
the one that is provided by RHEL as fuse.
Dave
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
--
Stephen J Smoogen.
11:49 a.m.
On Fri, Apr 05, 2019 at 11:04:46AM -0400, Stephen John Smoogen wrote:
On Fri, 5 Apr 2019 at 10:14, David Dykstra <dwd(a)fnal.gov>
wrote:
...
> Since RHEL already includes fuse/fuse-libs rpms, my intention is
to
> update the .spec file so those will not build on el6 & 7, leaving only
> fuse3/fuse3-libs. On the other hand, I'm not sure rpmbuild will be
> happy with having a fuse.spec that does not generate a fuse rpm, I will
> try it. I guess the alternative would be to split fuse3 out into a
> separate pagure/bodhi/koji package but it would be good to avoid that.
I believe that you need to rename the src.rpm spec to being fuse3 for
this to work with koji. Even though your package is not building fuse2
items, koji uses the src.rpm and will see yours as being newer than
the one that is provided by RHEL as fuse.
Does this also imply a new fuse3 package in pagure & bodhi? Or could it
still be part of the fuse package but have a separate fuse3.spec?
Dave
12:33 p.m.
>>>> "DD" == David Dykstra <dwd(a)fnal.gov>
writes:
DD> Does this also imply a new fuse3 package in pagure & bodhi? Or
DD> could it still be part of the fuse package but have a separate
DD> fuse3.spec?
It would have to be a separate package repository and receive separate
updates. It is not possible for a source package in EPEL to have the
same name as a source package in RHEL, even if the build products
(binary RPMs) have different names.
Note that a package review is not required to create a package
repository named "fuse3" (or "fuse3.7" or whatever) when the
"fuse"
package repository already exists. See
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuideline...
When running fedpkg request-repo, use the --exception flag.
- J<
1:07 p.m.
Thanks a lot for the helpful answer. I will request the fuse3 repo or
get the current fuse maintainer to do it.
Dave
On Fri, Apr 05, 2019 at 12:33:37PM -0500, Jason L Tibbitts III wrote:
> >>>>> "DD" == David Dykstra <dwd(a)fnal.gov> writes:
>
> DD> Does this also imply a new fuse3 package in pagure & bodhi? Or
> DD> could it still be part of the fuse package but have a separate
> DD> fuse3.spec?
>
> It would have to be a separate package repository and receive separate
> updates. It is not possible for a source package in EPEL to have the
> same name as a source package in RHEL, even if the build products
> (binary RPMs) have different names.
>
> Note that a package review is not required to create a package
> repository named "fuse3" (or "fuse3.7" or whatever) when the
"fuse"
> package repository already exists. See
>
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuideline...
> When running fedpkg request-repo, use the --exception flag.
>
> - J<
1857
days inactive
1857
days old
epel-devel@lists.fedoraproject.org
4 comments
3 participants
participants (3)
-
David Dykstra -
Jason L Tibbitts III -
Stephen John Smoogen