Re: [gentoo-dev] New eclass: db-use-r1
> # @ECLASS_VARIABLE: DB_VERSIONS
> # @REQUIRED
> # @DESCRIPTION:
> # This variable contains a list of sys-libs/db SLOT versions the package
> # works with. Please always sort the list so that higher slot versions come
> # first or else the package might not depend on the latest possible version of
> # sys-libs/db
> #
> # Example:
> # @CODE
> # DB_VERSIONS=( 5.0 4.8 )
> # inherit db-use-r1
> # @CODE
> #
> # Please note that you can also use bash brace expansion if you like:
> # @CODE
> # DB_VERSIONS=( 5.{3,2,1,0} 4.8 )
> # inherit db-use-r1
> # @CODE
> if ! declare -p DB_VERSIONS &>/dev/null; then
> die "DB_VERSIONS not declared."
> fi
You may want to add here an additional check if it is an array. Otherwise,
you may end up with some random behavior when someone sets it to single
string.
> # @ECLASS-VARIABLE: DB_DEPS
> # @DESCRIPTION:
> # This eclass sets and exports DB_DEPS which should be uses as follows:
> #
> # @CODE
> # RDEPEND="${DB_DEPEND}"
> # @CODE
DB_DEPS or DB_DEPEND?
> #
> # or
> #
> # @CODE
> # RDEPEND="berkdb? ( ${DB_DEPEND} )"
> # @CODE
> DB_DEPEND=""
> if [ "${#DB_VERSIONS[@]}" -gt 1 ] ; then
> DB_DEPEND="|| ("
> fi
I think it's perfectly valid to have '|| ( single-atom )'. IMO it's not
worth the effort to add it conditionally.
> for db_slotver in ${DB_VERSIONS[@]} ; do
> DB_DEPEND+=" sys-libs/db:${db_slotver}"
> done
You can do it without the loop:
DB_DEPEND+=${DB_VERSIONS[@]/#/ sys-libs/db:}
> if [ "${#DB_VERSIONS[@]}" -gt 1 ] ; then
> DB_DEPEND+=" )"
> fi
> export DB_DEPEND
> [[ ! -n ${DB_DEPEND} ]] && die "Cannot assing sys-libs/db dependency"
Looks like impossible to me. Well, unless DB_VERSIONS are empty but then
it looks like erring on the result rather than reason.
> inherit versionator multilib
>
> # @FUNCTION: db_ver_to_slot
> # @USAGE:
> # @DESCRIPTION:
> # Convert a version to a db slot. You need to submit at least the first two
> # Version components
> # This is meant for ebuilds using the real version number of a sys-libs/db
> # package. This eclass doesn't use it internally.
> db_ver_to_slot() {
> if [ $# -ne 1 ]; then
> eerror "Function db_ver_to_slot needs one argument" >&2
Shouldn't eerror use stderr on itself?
> eerror "args given:" >&2
> for f in $@
Missing quoting.
> do
> eerror " - \"$@\"" >&2
> done
> return 1
> fi
> if [ "$(get_version_component_count $1)" -lt 2 ] ; then
> eerror "db_ver_to_slot function needs at least a version
> component"
> eerror "count of two."
> return 1
'die', please.
> fi
> echo -n "$(get_version_component_range 1-2 $1)"
Just FYI, '-n' is not really necessary here since shell automatically
strips trailing newline in $().
> }
>
> # @FUNCTION: db_findver
> # @USAGE:
> # @DESCRIPTION:
> # Find the highest installed db version that fits DB_VERSIONS
> db_findver() {
> local db_slotver
> for db_slotver in ${DB_VERSIONS[@]} ; do
> if has_version sys-libs/db:${db_slotver} \
> && [ -d "/usr/include/db${db_slotver}" ] ; then
Why do you need both checks?
> echo -n "${db_slotver}"
> return 0
> fi
> done
> return 1
> }
>
> # @FUNCTION: db_includedir
> # @USAGE:
> # @DESCRIPTION:
> # Get the include dir for berkeley db. This function returns the best version
> # found by db_findver()
> db_includedir() {
> VER="$(db_findver)" || return 1
Shouldn't this be 'local'?
> einfo "include version ${VER}" >&2
Looks more like debug-print candidate. Or, at least mention 'berkdb'
somewhere since user will have no idea 'version of what'.
> if [ -d "/usr/include/db${VER}" ]; then
> echo -n "/usr/include/db${VER}"
> return 0
> else
> eerror "sys-libs/db package requested, but headers not found"
> >&2
> return 1
> fi
> }
>
> # @FUNCTION: db_libname
> # @USAGE:
> # @DESCRIPTION:
> # Get the library name for berkeley db. Something like "db-4.2" will be the
> # outcome. This function returns the best version found by db_findver()
> db_libname() {
> VER="$(db_findver)" || return 1
> if [ -e "/usr/$(get_libdir)/libdb-${VER}.so" ]; then
> echo -n "db-${VER}"
> return 0
> else
> eerror "sys-libs/db package requested, but library not found"
> >&2
> return 1
> fi
> }
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] New eclass: db-use-r1
Hi list, I'd like to propose a new eclass "db-use-r1" [1]. While working on the dev-libs/Ice package I found it to fail with sys- libs/db:6.0 (see [2]) and I have found no way to use current db-use.eclass to make Ice compile against an older sys-libs/db slot if db:6.0 is installed. So I'd like to ask for a review of the new eclass which has a few important changes compared to the old db-use.eclass: - It requires ebuilds using the eclass to define DB_VERSIONS variable - It provides avariable DB_DEPEND containing all possible db:slot versions a package can use - db_findver() no longer blindly returns latest installed sys-libs/db version. it now returns the best version from DB_VERSIONS if any is installed. I'd like to commit this eclass into portage in about a week if no veto appears. Thanks Lars [1] http://dev.gentoo.org/~polynomial-c/db-use-r1.eclass [2] https://bugs.gentoo.org/476378 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass db-use
On Thursday 18 May 2006 15:49, Simon Stelling wrote: > Paul de Vrieze wrote: > > Unfortunately this GLEP has not been implemented yet. This eclass > > would indeed be an ideal elib. Also, for this eclass the API > > requirements are not as strict as it is only intended to be used in > > unpack and compile stages. > > That's not my point. I mentioned it because it briefly shows why the > current eclass system has its problems and why contacting -dev *before* > adding a new eclass to the tree is essential. I see your point. This GLEP does not require contacting -dev at all though. Instead of this eclass I could have abused the db4fix eclass and be done with it. The new one has a better name, and sane design. It offers functions (and will offer more) that are long due and actually help ebuilds using berkeley db. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpMLoZNa12tG.pgp Description: PGP signature
Re: [gentoo-dev] New eclass db-use
Paul de Vrieze wrote: Unfortunately this GLEP has not been implemented yet. This eclass would indeed be an ideal elib. Also, for this eclass the API requirements are not as strict as it is only intended to be used in unpack and compile stages. That's not my point. I mentioned it because it briefly shows why the current eclass system has its problems and why contacting -dev *before* adding a new eclass to the tree is essential. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass db-use
On Thursday 18 May 2006 15:06, Simon Stelling wrote: > Paul de Vrieze wrote: > > It has not been. As far as I know such a requirement does not exist. > > In > > It does. The reason for it is pretty good, as kloeri mentioned: The API > of an eclass may never change. See GLEP 33 for some horror scenarios > [1] ;) Unfortunately this GLEP has not been implemented yet. This eclass would indeed be an ideal elib. Also, for this eclass the API requirements are not as strict as it is only intended to be used in unpack and compile stages. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpwYX4EHPlx1.pgp Description: PGP signature
Re: [gentoo-dev] New eclass db-use
Paul de Vrieze wrote: It has not been. As far as I know such a requirement does not exist. In It does. The reason for it is pretty good, as kloeri mentioned: The API of an eclass may never change. See GLEP 33 for some horror scenarios [1] ;) [1] http://www.gentoo.org/proj/en/glep/glep-0033.html -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass db-use
On Thursday 18 May 2006 13:25, Bryan Ãstergaard wrote: > Was this discussed on gentoo-dev mailinglist before committing to the > tree? Eclasses are supposed to be discussed on -dev prior to adding > them to the tree to catch any (obvious) mistakes etc. > > This is particularly important for eclasses as they can't be removed or > changed in incompatible ways later due to the way portage handles them. > > I don't have time to look at it myself right now but I'd still > appreciate posting the code to gentoo-dev and have other devs/users > comment on it. It has not been. As far as I know such a requirement does not exist. In any case, this eclass only provides utility functions to find the proper location of berkeley db. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpZstvic3TD7.pgp Description: PGP signature
Re: [gentoo-dev] New eclass db-use
On Thu, May 18, 2006 at 11:48:50AM +0200, Paul de Vrieze wrote:
>
> Hi all,
>
> I have just committed a new eclass to the tree. This eclass has as purpose
> to make it easier to use berkeley db. Currently the eclass has two
> interesting functions (and some helpers that may or may not be
> interesting).
>
> These functions are:
> db_includedir
> db_libname
>
> Both functions can be used with and without arguments. Without arguments
> they will give the best bdb version. With arguments they will loop
> through the arguments which are version prefixes (they will be matched
> with "=sys-libs/db-${1}*"
>
> The includedir function returns the include dir of the best matched db
> version. The libname function returns the libraryname of the best matched
> db. This libraryname has the form db-${ver}, and as such could be just
> appended to "-l". This means it is not the filename.
>
Was this discussed on gentoo-dev mailinglist before committing to the
tree? Eclasses are supposed to be discussed on -dev prior to adding them
to the tree to catch any (obvious) mistakes etc.
This is particularly important for eclasses as they can't be removed or
changed in incompatible ways later due to the way portage handles them.
I don't have time to look at it myself right now but I'd still
appreciate posting the code to gentoo-dev and have other devs/users
comment on it.
Regards,
Bryan Østergaard
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] New eclass db-use
Hi all,
I have just committed a new eclass to the tree. This eclass has as purpose
to make it easier to use berkeley db. Currently the eclass has two
interesting functions (and some helpers that may or may not be
interesting).
These functions are:
db_includedir
db_libname
Both functions can be used with and without arguments. Without arguments
they will give the best bdb version. With arguments they will loop
through the arguments which are version prefixes (they will be matched
with "=sys-libs/db-${1}*"
The includedir function returns the include dir of the best matched db
version. The libname function returns the libraryname of the best matched
db. This libraryname has the form db-${ver}, and as such could be just
appended to "-l". This means it is not the filename.
Paul;
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgpp0TxceMdlj.pgp
Description: PGP signature
