<p>Em 20/07/2011 10:42, "rupert THURNER" <<a href="mailto:rupert@opencsw.org">rupert@opencsw.org</a>> escreveu:<br>
><br>
> 2011/7/20 Maciej Bliziński <<a href="mailto:maciej.blizinski@gmail.com">maciej.blizinski@gmail.com</a>>:<br>
> > Em 19/07/2011 22:39, <<a href="mailto:rthurner@users.sourceforge.net">rthurner@users.sourceforge.net</a>> escreveu:<br>
> >><br>
> >> Revision: 15128<br>
> >> <a href="http://gar.svn.sourceforge.net/gar/?rev=15128&view=rev">http://gar.svn.sourceforge.net/gar/?rev=15128&view=rev</a><br>
> >> Author: rthurner<br>
> >> Date: 2011-07-19 21:38:57 +0000 (Tue, 19 Jul 2011)<br>
> >><br>
> >> Log Message:<br>
> >> -----------<br>
> >> apr, try to adjust to new checkpkg ... seems not to make a lot of sense<br>
> >> like this<br>
> >><br>
> >> Modified Paths:<br>
> >> --------------<br>
> >> csw/mgar/pkg/apr/trunk/Makefile<br>
> >><br>
> >> Modified: csw/mgar/pkg/apr/trunk/Makefile<br>
> >> ===================================================================<br>
> >> --- csw/mgar/pkg/apr/trunk/Makefile 2011-07-19 21:20:37 UTC (rev<br>
> >> 15127)<br>
> >> +++ csw/mgar/pkg/apr/trunk/Makefile 2011-07-19 21:38:57 UTC (rev<br>
> >> 15128)<br>
> >> @@ -11,14 +11,18 @@<br>
> >><br>
> >> MASTER_SITES = <a href="http://apache.crihan.fr/dist/apr/">http://apache.crihan.fr/dist/apr/</a><br>
> >> DISTFILES = $(NAME)-$(VERSION).tar.gz<br>
> >> -<br>
> >> +LICENSE = LICENSE<br>
> >> PATCHFILES = 0001-Force-newly-built-libs-in-testsuite.patch<br>
> >><br>
> >> -LICENSE = LICENSE<br>
> >><br>
> >> -# We define upstream file regex so we can be notifed of new upstream<br>
> >> software release<br>
> >> -UFILES_REGEX = $(NAME)-(\d+(?:\.\d+)*).tar.gz<br>
> >> +PACKAGES += CSWapr-dev<br>
> >> +CATALOGNAME_CSWapr-dev = apr_dev<br>
> >> +PKGFILES_CSWapr-dev += /opt/csw/lib/libapr-1.so<br>
> >> +PKGFILES_CSWapr-dev += /opt/csw/lib/sparcv9/libapr-1.so<br>
> >> +CHECKPKG_OVERRIDES_CSWapr-dev +=<br>
> >> file-collision|/opt/csw/lib/libapr-1.so|CSWapr|CSWapr-dev<br>
> >> +CHECKPKG_OVERRIDES_CSWapr-dev +=<br>
> >> file-collision|/opt/csw/lib/sparcv9/libapr-1.so|CSWapr|CSWapr-dev<br>
> ><br>
> > Hi Rupert,<br>
> ><br>
> > In normal circumstances you should never override file collision error tags.<br>
> > What's your plan, do you want to ship the same file in two packages?<br>
><br>
> honestly, i have no idea what checkpackage wants me to do with apr. i<br>
> have no idea what it wants me to do with apr-util. </p>
<p>There are two main sources of information: one is checkpkg screen output, the one you quoted below about the .so symlinks looks fairly straightforward. You can verify whether what checkpkg says is true. For example, you can check these .so files. </p>
<p>The other source is the wiki page with error tag descriptions. I recommend taking a look at it. Start at the OpenCSW wiki main page and search for "checkpkg error tags". </p>
<p>> from a completely<br>
> egoistic standpoint i consider software that i cannot understand<br>
> anymore in 5 minutes and i cannot google the solution for in 5 minutes<br>
> as unusable. gar and checkpkg meet that criteria currently.</p>
<p>I don't know how to answer. As a maintainer, you need to understand packaging policies. What checkpkg does, is it examines your packages and shows error tags when it discovers something that looks like a problem. If you don't know the underlying policies, shown tags will probably make little sense.</p>
<p>From looking at the commit logs, when checkpkg reports genuine problems, you override the error tags without consulting anyone. In other cases when you see a false positive, you consider it a roadblock. Neither response is optimal.</p>
<p>> i only want to get an apr package that works. as simple as possible.<br>
> do not want to have two packages if one is sufficient.</p>
<p>Have you familiarized yourself with the shared libraries packaging policy? It is available on the wiki.</p>
<p>In the case of apr and aprutil, Dago seems to have sorted these packages out, so take a look at the recipes and make sure you understand what they do. </p>
<p>Maciej</p>
<p>><br>
> to go a little more in detail, the output i get now with dagos<br>
> adjusted apr-util, and his changeset<br>
> <a href="http://sourceforge.net/apps/trac/gar/changeset/15147/csw/mgar">http://sourceforge.net/apps/trac/gar/changeset/15147/csw/mgar</a><br>
><br>
><br>
> CSWlibaprutil1-0:<br>
> * The package contains shared libraries together with the symlink of the form<br>
> libfoo.so -> libfoo.so.1. In this case: /opt/csw/lib/apr-<br>
> util-1/apr_dbd_odbc.so. This kind of symlink should not be together with<br>
> the shared libraries; it is only used during compiling and linking. The<br>
> best practice is to put the shared libraries into a separate package, and<br>
> the .so file together with the header files in the devel package.<br>
> * The package contains shared libraries together with the symlink of the form<br>
> libfoo.so -> libfoo.so.1. In this case: /opt/csw/lib/apr-<br>
> util-1/apr_dbd_sqlite3.so. This kind of symlink should not be together<br>
> with the shared libraries; it is only used during compiling and linking.<br>
> The best practice is to put the shared libraries into a separate package,<br>
> and the .so file together with the header files in the devel package.<br>
> * The package contains shared libraries together with the symlink of the form<br>
> libfoo.so -> libfoo.so.1. In this case: /opt/csw/lib/apr-<br>
> util-1/apr_dbm_db.so. This kind of symlink should not be together with the<br>
> shared libraries; it is only used during compiling and linking. The best<br>
> practice is to put the shared libraries into a separate package, and the<br>
> .so file together with the header files in the devel package.<br>
> * The package contains shared libraries together with the symlink of the form<br>
> libfoo.so -> libfoo.so.1. In this case: /opt/csw/lib/apr-<br>
> util-1/apr_ldap.so. This kind of symlink should not be together with the<br>
> shared libraries; it is only used during compiling and linking. The best<br>
> practice is to put the shared libraries into a separate package, and the<br>
> .so file together with the header files in the devel package.<br>
> * The package contains shared libraries together with the symlink of the form<br>
> libfoo.so -> libfoo.so.1. In this case: /opt/csw/lib/apr-<br>
> util-1/apr_dbd_odbc.so. This kind of symlink should not be together with<br>
> the shared libraries; it is only used during compiling and linking. The<br>
> best practice is to put the shared libraries into a separate package, and<br>
> the .so file together with the header files in the devel package.<br>
> * The package contains shared libraries together with the symlink of the form<br>
> libfoo.so -> libfoo.so.1. In this case: /opt/csw/lib/apr-<br>
> util-1/apr_dbd_sqlite3.so. This kind of symlink should not be together<br>
> with the shared libraries; it is only used during compiling and linking.<br>
> The best practice is to put the shared libraries into a separate package,<br>
> and the .so file together with the header files in the devel package.<br>
> * The package contains shared libraries together with the symlink of the form<br>
> libfoo.so -> libfoo.so.1. In this case: /opt/csw/lib/apr-<br>
> util-1/apr_dbm_db.so. This kind of symlink should not be together with the<br>
> shared libraries; it is only used during compiling and linking. The best<br>
> practice is to put the shared libraries into a separate package, and the<br>
> .so file together with the header files in the devel package.<br>
> * The package contains shared libraries together with the symlink of the form<br>
> libfoo.so -> libfoo.so.1. In this case: /opt/csw/lib/apr-<br>
> util-1/apr_ldap.so. This kind of symlink should not be together with the<br>
> shared libraries; it is only used during compiling and linking. The best<br>
> practice is to put the shared libraries into a separate package, and the<br>
> .so file together with the header files in the devel package.<br>
> * Dependency issues of CSWapr-util:<br>
> * If you don't know of any reasons to include these dependencies, you might<br>
> remove them:<br>
> * ? CSWlibaprutil1-0<br>
><br>
> # Checkpkg suggests adding the following lines to the GAR recipe:<br>
> # This is a summary; see above for details.<br>
> # (If CSWlibaprutil1-0-dev doesn't exist yet)<br>
> PACKAGES += CSWlibaprutil1-0-dev<br>
> PKGFILES_CSWlibaprutil1-0-dev += /opt/csw/lib/apr-util-1/apr_dbd_odbc.so<br>
> CATALOGNAME_CSWlibaprutil1-0-dev = libaprutil1_0_dev<br>
> # (If CSWlibaprutil1-0-dev doesn't exist yet)<br>
> PACKAGES += CSWlibaprutil1-0-dev<br>
> PKGFILES_CSWlibaprutil1-0-dev += /opt/csw/lib/apr-util-1/apr_dbd_sqlite3.so<br>
> CATALOGNAME_CSWlibaprutil1-0-dev = libaprutil1_0_dev<br>
> # (If CSWlibaprutil1-0-dev doesn't exist yet)<br>
> PACKAGES += CSWlibaprutil1-0-dev<br>
> PKGFILES_CSWlibaprutil1-0-dev += /opt/csw/lib/apr-util-1/apr_dbm_db.so<br>
> CATALOGNAME_CSWlibaprutil1-0-dev = libaprutil1_0_dev<br>
> # (If CSWlibaprutil1-0-dev doesn't exist yet)<br>
> PACKAGES += CSWlibaprutil1-0-dev<br>
> PKGFILES_CSWlibaprutil1-0-dev += /opt/csw/lib/apr-util-1/apr_ldap.so<br>
> CATALOGNAME_CSWlibaprutil1-0-dev = libaprutil1_0_dev<br>
> WARNING: Some overrides did not match any errors. They can be removed, as they<br>
> don't take any effect anyway. If you're getting errors at the same time, maybe<br>
> you didn't specify the overrides correctly.<br>
> * Unused Override: CSWapr-util: archall-devel-package<br>
><br>
> The following packages have been built:<br>
><br>
> CSWapr-util<br>
> /home/rupert/pkgs/20.Jul.2011/apr_util_stub-1.3.12,REV=2011.07.20-SunOS5.9-all-CSW.pkg.gz<br>
> CSWlibaprutil-dev<br>
> /home/rupert/pkgs/20.Jul.2011/libaprutil_dev-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz<br>
> CSWlibaprutil1-0<br>
> /home/rupert/pkgs/20.Jul.2011/libaprutil1_0-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz<br>
><br>
> [package] complete for apr-util.<br>
</p>