[csw-devel] SF.net SVN: gar:[15128] csw/mgar/pkg/apr/trunk/Makefile

Maciej Bliziński maciej at opencsw.org
Thu Jul 21 20:29:50 CEST 2011 

Em 20/07/2011 10:42, "rupert THURNER" <rupert at opencsw.org> escreveu:
>
> 2011/7/20 Maciej Bliziński <maciej.blizinski at gmail.com>:
> > Em 19/07/2011 22:39, <rthurner at users.sourceforge.net> escreveu:
> >>
> >> Revision: 15128
> >>          http://gar.svn.sourceforge.net/gar/?rev=15128&view=rev
> >> Author:   rthurner
> >> Date:     2011-07-19 21:38:57 +0000 (Tue, 19 Jul 2011)
> >>
> >> Log Message:
> >> -----------
> >> apr, try to adjust to new checkpkg ... seems not to make a lot of sense
> >> like this
> >>
> >> Modified Paths:
> >> --------------
> >>    csw/mgar/pkg/apr/trunk/Makefile
> >>
> >> Modified: csw/mgar/pkg/apr/trunk/Makefile
> >> ===================================================================
> >> --- csw/mgar/pkg/apr/trunk/Makefile     2011-07-19 21:20:37 UTC (rev
> >> 15127)
> >> +++ csw/mgar/pkg/apr/trunk/Makefile     2011-07-19 21:38:57 UTC (rev
> >> 15128)
> >> @@ -11,14 +11,18 @@
> >>
> >>  MASTER_SITES = http://apache.crihan.fr/dist/apr/
> >>  DISTFILES  = $(NAME)-$(VERSION).tar.gz
> >> -
> >> +LICENSE = LICENSE
> >>  PATCHFILES = 0001-Force-newly-built-libs-in-testsuite.patch
> >>
> >> -LICENSE = LICENSE
> >>
> >> -# We define upstream file regex so we can be notifed of new upstream
> >> software release
> >> -UFILES_REGEX = $(NAME)-(\d+(?:\.\d+)*).tar.gz
> >> +PACKAGES += CSWapr-dev
> >> +CATALOGNAME_CSWapr-dev = apr_dev
> >> +PKGFILES_CSWapr-dev += /opt/csw/lib/libapr-1.so
> >> +PKGFILES_CSWapr-dev += /opt/csw/lib/sparcv9/libapr-1.so
> >> +CHECKPKG_OVERRIDES_CSWapr-dev +=
> >> file-collision|/opt/csw/lib/libapr-1.so|CSWapr|CSWapr-dev
> >> +CHECKPKG_OVERRIDES_CSWapr-dev +=
> >> file-collision|/opt/csw/lib/sparcv9/libapr-1.so|CSWapr|CSWapr-dev
> >
> > Hi Rupert,
> >
> > In normal circumstances you should never override file collision error
tags.
> > What's your plan, do you want to ship the same file in two packages?
>
> honestly, i have no idea what checkpackage wants me to do with apr. i
> have no idea what it wants me to do with apr-util.

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.

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".

> from a completely
> egoistic standpoint i consider software that i cannot understand
> anymore in 5 minutes and i cannot google the solution for in 5 minutes
> as unusable. gar and checkpkg meet that criteria currently.

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.

>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.

> i only want to get an apr package that works. as simple as possible.
> do not want to have two packages if one is sufficient.

Have you familiarized yourself with the shared libraries packaging policy?
It is available on the wiki.

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.

Maciej

>
> to go a little more in detail, the output i get now with dagos
> adjusted apr-util, and his changeset
> http://sourceforge.net/apps/trac/gar/changeset/15147/csw/mgar
>
>
> CSWlibaprutil1-0:
>  * The package contains shared libraries together with the symlink of the
form
>   libfoo.so -> libfoo.so.1.  In this case: /opt/csw/lib/apr-
>   util-1/apr_dbd_odbc.so.  This kind of symlink should not be together
with
>   the shared libraries; it is only used during compiling and linking.  The
>   best practice is to put the shared libraries into a separate package,
and
>   the .so file together with the header files in the devel package.
>  * The package contains shared libraries together with the symlink of the
form
>   libfoo.so -> libfoo.so.1.  In this case: /opt/csw/lib/apr-
>   util-1/apr_dbd_sqlite3.so.  This kind of symlink should not be together
>   with the shared libraries; it is only used during compiling and linking.
>   The best practice is to put the shared libraries into a separate
package,
>   and the .so file together with the header files in the devel package.
>  * The package contains shared libraries together with the symlink of the
form
>   libfoo.so -> libfoo.so.1.  In this case: /opt/csw/lib/apr-
>   util-1/apr_dbm_db.so.  This kind of symlink should not be together with
the
>   shared libraries; it is only used during compiling and linking.  The
best
>   practice is to put the shared libraries into a separate package, and the
>   .so file together with the header files in the devel package.
>  * The package contains shared libraries together with the symlink of the
form
>   libfoo.so -> libfoo.so.1.  In this case: /opt/csw/lib/apr-
>   util-1/apr_ldap.so.  This kind of symlink should not be together with
the
>   shared libraries; it is only used during compiling and linking.  The
best
>   practice is to put the shared libraries into a separate package, and the
>   .so file together with the header files in the devel package.
>  * The package contains shared libraries together with the symlink of the
form
>   libfoo.so -> libfoo.so.1.  In this case: /opt/csw/lib/apr-
>   util-1/apr_dbd_odbc.so.  This kind of symlink should not be together
with
>   the shared libraries; it is only used during compiling and linking.  The
>   best practice is to put the shared libraries into a separate package,
and
>   the .so file together with the header files in the devel package.
>  * The package contains shared libraries together with the symlink of the
form
>   libfoo.so -> libfoo.so.1.  In this case: /opt/csw/lib/apr-
>   util-1/apr_dbd_sqlite3.so.  This kind of symlink should not be together
>   with the shared libraries; it is only used during compiling and linking.
>   The best practice is to put the shared libraries into a separate
package,
>   and the .so file together with the header files in the devel package.
>  * The package contains shared libraries together with the symlink of the
form
>   libfoo.so -> libfoo.so.1.  In this case: /opt/csw/lib/apr-
>   util-1/apr_dbm_db.so.  This kind of symlink should not be together with
the
>   shared libraries; it is only used during compiling and linking.  The
best
>   practice is to put the shared libraries into a separate package, and the
>   .so file together with the header files in the devel package.
>  * The package contains shared libraries together with the symlink of the
form
>   libfoo.so -> libfoo.so.1.  In this case: /opt/csw/lib/apr-
>   util-1/apr_ldap.so.  This kind of symlink should not be together with
the
>   shared libraries; it is only used during compiling and linking.  The
best
>   practice is to put the shared libraries into a separate package, and the
>   .so file together with the header files in the devel package.
>  * Dependency issues of CSWapr-util:
>  * If you don't know of any reasons to include these dependencies, you
might
>   remove them:
>  * ? CSWlibaprutil1-0
>
> # Checkpkg suggests adding the following lines to the GAR recipe:
> # This is a summary; see above for details.
> # (If CSWlibaprutil1-0-dev doesn't exist yet)
> PACKAGES += CSWlibaprutil1-0-dev
> PKGFILES_CSWlibaprutil1-0-dev += /opt/csw/lib/apr-util-1/apr_dbd_odbc.so
> CATALOGNAME_CSWlibaprutil1-0-dev = libaprutil1_0_dev
> # (If CSWlibaprutil1-0-dev doesn't exist yet)
> PACKAGES += CSWlibaprutil1-0-dev
> PKGFILES_CSWlibaprutil1-0-dev +=
/opt/csw/lib/apr-util-1/apr_dbd_sqlite3.so
> CATALOGNAME_CSWlibaprutil1-0-dev = libaprutil1_0_dev
> # (If CSWlibaprutil1-0-dev doesn't exist yet)
> PACKAGES += CSWlibaprutil1-0-dev
> PKGFILES_CSWlibaprutil1-0-dev += /opt/csw/lib/apr-util-1/apr_dbm_db.so
> CATALOGNAME_CSWlibaprutil1-0-dev = libaprutil1_0_dev
> # (If CSWlibaprutil1-0-dev doesn't exist yet)
> PACKAGES += CSWlibaprutil1-0-dev
> PKGFILES_CSWlibaprutil1-0-dev += /opt/csw/lib/apr-util-1/apr_ldap.so
> CATALOGNAME_CSWlibaprutil1-0-dev = libaprutil1_0_dev
> WARNING: Some overrides did not match any errors. They can be removed, as
they
> don't take any effect anyway.  If you're getting errors at the same time,
maybe
> you didn't specify the overrides correctly.
> * Unused Override: CSWapr-util: archall-devel-package
>
> The following packages have been built:
>
>  CSWapr-util
>
/home/rupert/pkgs/20.Jul.2011/apr_util_stub-1.3.12,REV=2011.07.20-SunOS5.9-all-CSW.pkg.gz
>  CSWlibaprutil-dev
>
/home/rupert/pkgs/20.Jul.2011/libaprutil_dev-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz
>  CSWlibaprutil1-0
>
/home/rupert/pkgs/20.Jul.2011/libaprutil1_0-1.3.12,REV=2011.07.20-SunOS5.9-sparc-CSW.pkg.gz
>
>        [package] complete for apr-util.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/devel/attachments/20110721/cc9f5bc3/attachment-0001.html>

More information about the devel mailing list