Bug 202755

Summary: Can module mod_quotatab be included in proftpd RPM?
Product: [Fedora] Fedora Reporter: Johan Kok <johan-fedora>
Component: proftpdAssignee: Matthias Saou <matthias>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 5CC: extras-qa
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-23 14:55:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Diff for spec file with added mod_quotatab none

Description Johan Kok 2006-08-16 10:35:46 UTC 
Description of problem:
I'm using proftpd's mod_quotatab_ldap module to enforce storage limits for ftp
users. Whenever a update of proftpd arrives I use a modified spec file to create
a new RPM that contains this mod_quotatab module. My question: is it possible to
include the module in the FE proftpd package?

I attached a diff from the spec file where I added mod_quotatab subpackages. The
mod_quotatab module is seperated in different modules for filesystem, ldap and
sql backends. 

Version-Release number of selected component (if applicable):
1.3.0
Comment 1 Johan Kok 2006-08-16 10:35:50 UTC 
Created attachment 134291 [details]
Diff for spec file with added mod_quotatab
Comment 2 Matthias Saou 2006-08-22 11:12:02 UTC 
If the mod_quotatab module itself doesn't add any new library dependency, why
not include it in the main package? After, it would also make sense to include
the ldap quota module into the existing ldap sub-package and the sql one either
in the main or in both mysql and postgresql sub-packages. What do you think?
Comment 3 Johan Kok 2006-08-22 18:18:01 UTC 
(In reply to comment #2)
>[...] What do you think?

By packaging the module in a seperate package the user has a choice to
install/use the module or not. Now that I think about it, packaging the module
as DSO the user has the choice to load (or not load) the module in their
installation. Packaging the module in the main packages sounds right: it's not a
very large module and 4 sub-packages is a bit much.

Your suggestion to package the ldap/sql mod_quotatab modules with the
corresponding module sounds fine. I would package the mod_quotatab and
mod_quotatab_file modules in the main package: in that case a user can use all
the basic functions of the module with the main package.
Comment 4 Matthias Saou 2006-08-23 08:05:41 UTC 
Yup, sounds like the right way to do things. I'll do that ASAP and push an
updated package first for devel, then to previous FC releases if all seems fine.
Comment 5 Matthias Saou 2006-08-23 14:55:23 UTC 
New packages with the new modules will be available with the next push.

Note that I've included a copy of the *_sql module in both mysql and postgresl
sub-packages. This is definitely something that I prefer trying to avoid, but
rpm permits it (since both files are absolutely identical), and it avoids
putting the module in the main package (which doesn't make much sense) or the
hassle of a new sub-package and virtual provides in both backend sub-packages...
just a FYI :-)
Comment 6 Johan Kok 2006-08-23 15:41:30 UTC 
(In reply to comment #5)
> New packages with the new modules will be available with the next push.

Thanks! I'll give them a try. 

> Note that I've included a copy of the *_sql module in both mysql and postgresl
> sub-packages. This is definitely something that I prefer trying to avoid, but
> rpm permits it (since both files are absolutely identical), and it avoids
> putting the module in the main package (which doesn't make much sense) or the
> hassle of a new sub-package and virtual provides in both backend sub-packages...
> just a FYI :-)

Sounds like the same solution I would choose :)