The following issue has been RESOLVED. 
====================================================================== 
http://www.dbmail.org/mantis/view.php?id=510 
====================================================================== 
Reported By:                bjohnson
Assigned To:                paul
====================================================================== 
Project:                    DBMail
Issue ID:                   510
Category:                   General
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     resolved
target:                      
Resolution:                 fixed
Fixed in Version:           2.2.3
====================================================================== 
Date Submitted:             22-Feb-07 00:38 CET
Last Modified:              26-Feb-07 10:47 CET
====================================================================== 
Summary:                    libsqlite.so.* is build even when --with-sqlite is
not specified
Description: 
Building dbmail without --with-sqlite still produces libsqlite.so.* files.

Even when built on a system that does not have sqlite!


====================================================================== 

---------------------------------------------------------------------- 
 paul - 26-Feb-07 09:29  
---------------------------------------------------------------------- 
So what's the problem here, really. Those .so files are pretty much empty
stubs. If the fact that libtool builds them annoyes you this would be a
cosmetic issue at best. 

---------------------------------------------------------------------- 
 bjohnson - 26-Feb-07 10:09  
---------------------------------------------------------------------- 
Having libsqlite.so.* file on the system where there is no support for
sqlite is confusing at best.  I was building this as a package for
Fedora/CentOS when I came across this.  At first, I though it was a
problem with configure not obeying the options correctly.  Then after
removing any sqlite devel libs so it would be impossible to build support,
it became apparent that it was always built.

When I first started building the packages, I expected there to only be
files that I had asked for (as specific sub-packages pick up certain files
to reduce dependency bloat).  What happened, in rpm, is a safeguard check
that triggered an unexpected unpackaged file error - this terminates the
rpm build.

So then, in the package you have to specifically go and delete this file
to make rpm happy.

While this is a trivial thing to have to do, it ups the bar slightly for
package maintenance.  Not only does it have to be removed, you then have
to document why you do such a silly thing as delete a .so.* group that
should never have been built to start with.

Still, this is trivial, until you multiply all these types of tiny fixes
by thousands packages, with maintainers coming and going.

As a maintainer of the RPM package in Fedora Extras, it's my job to notify
you (upstream) of things like this (and bug 509) as potential maintenance
issues, and, at least in the view of Fedora Extras packaging, an
undesirable feature.

We do this for many things that are deemed, at least in our project, to be
undesirable:
 1) mixing tabs and spaces in text files
 2) encoding other than UTF8
 3) using dos eol
 4) tarballs do not reflect package name and version
 5) improper or not included licenses
 6) executable documentation (or permission problems in general)
... and many more

In many cases we find that the authors are completely unaware of many of
these problems, and are happy to receive the feedback to fix issues that
they may have missed.  For example we also provided Aaron a report
regarding files in libsieve that were not LGPL (they were in fact GPL,
which changes the overall license of the package), and build problems
where make flags were not passed correctly.

It's this kind of scrutiny that helps produce quality packages for the
community.

As the upstream maintainer of the package, it's certainly your decision to
handle this however you want, and as long as it doesn't create a big burden
(it's not), security issue, license violation, or other terminal guideline
violation, we will respect that and continue to package within our
guidelines making changes as necessary. 

---------------------------------------------------------------------- 
 paul - 26-Feb-07 10:47  
---------------------------------------------------------------------- 
Ok. Fixed it. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
22-Feb-07 00:38 bjohnson       New Issue                                    
26-Feb-07 09:29 paul           Note Added: 0001839                          
26-Feb-07 09:29 paul           Severity                 minor => trivial    
26-Feb-07 09:29 paul           Status                   new => feedback     
26-Feb-07 10:09 bjohnson       Note Added: 0001844                          
26-Feb-07 10:47 paul           Note Added: 0001846                          
26-Feb-07 10:47 paul           Assigned To               => paul            
26-Feb-07 10:47 paul           Status                   feedback => resolved
26-Feb-07 10:47 paul           Resolution               open => fixed       
26-Feb-07 10:47 paul           Fixed in Version          => 2.2.3           
======================================================================

_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Reply via email to