Re: [gentoo-dev] VDB access
Ciaran McCreesh a écrit : The following things access VDB by hand: * gnome2-utils.eclass. Will be fixed once a portage with proper env saving goes stable, which isn't too far off. Bug 155993. Quick follow-up on that for everyone. The eclass has been modified not to access VDB anymore yet with all the bells and whistles to improve performance, and the concerned ebuilds have been updated. Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] VDB access
On Wed, 06 Feb 2008 23:41:31 -0800
Zac Medico [EMAIL PROTECTED] wrote:
if [[ -n ${E_INSTALLED_PKG_METADATA_CMD} ]] ; then
${E_INSTALLED_PKG_METADATA_CMD} =cat/pkg-1.23 USE foo
else
# old vdb stuff
fi
it would be handy if it supports something like the built_with_use -a
and -o options
Mmm, or we could just have it return the raw value. Slight difficulty
there in that it'd have to return IUSE etc in whatever format the
installed package's EAPI uses, but that's not too big a deal.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] VDB access
On Wed, 2008-02-06 at 07:30 +0100, Vlastimil Babka wrote: Zac Medico wrote: or we would want to use the general metadata query also for other purposes. Anyway, restricting ebuilds from vdb access sounds like a good idea to me. +1 for general metadata query interface. In prefix (specifically on AIX) we have some nasty requirement to merge object files inside archive files, because shared-objects should be members of a static libraries, fex libstdc++.so.6 is an archive member of libstdc++.a. This (still experimental) inside-library-merge currently is done using some hackery in profile.bashrc, but this requires access to vdb/CONTENTS in pre_pkg_postrm() to clean up after unmerge. /haubi/ -- Michael Haubenwallner Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] VDB access
On Tue, 05 Feb 2008 13:21:34 -0800
Zac Medico [EMAIL PROTECTED] wrote:
* Allow package managers that implement native_built_with_use to
sandbox off vdb completely, and ban all ebuild access to vdb.
The problem that I see with native_built_with_use is that the
package manager will then need to precisely implement the
build_with_use interface along with any and all supported options
(and this interface would effectively become part of the EAPI).
True.
If the package manager exposes a slightly lower level interface to
the USE flags then build_with_use can use that instead, and the
package manager won't have to implement the full build_with_use
interface. For example, portageq currently supports a metadata
command that can be used to query installed package metadata such as
USE and IUSE. Perhaps we should use some type of interface similar
to that.
That's also a possibility. How about something like:
if [[ -n ${E_INSTALLED_PKG_METADATA_CMD} ]] ; then
${E_INSTALLED_PKG_METADATA_CMD} =cat/pkg-1.23 USE foo
else
# old vdb stuff
fi
with heavy (and checked) restrictions upon legal metadata keys (stuff
that's in individual files, not environment.bz2)?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] VDB access
On Wed, 06 Feb 2008 14:24:28 +0100 Michael Haubenwallner [EMAIL PROTECTED] wrote: +1 for general metadata query interface. In prefix (specifically on AIX) we have some nasty requirement to merge object files inside archive files, because shared-objects should be members of a static libraries, fex libstdc++.so.6 is an archive member of libstdc++.a. This (still experimental) inside-library-merge currently is done using some hackery in profile.bashrc, but this requires access to vdb/CONTENTS in pre_pkg_postrm() to clean up after unmerge. CONTENTS isn't metadata in the conventional sense... If someone's redesigning VDB, they're very unlikely to keep CONTENTS in the same format. So you'd need a second, different interface for that... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] VDB access
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Tue, 05 Feb 2008 13:21:34 -0800
Zac Medico [EMAIL PROTECTED] wrote:
If the package manager exposes a slightly lower level interface to
the USE flags then build_with_use can use that instead, and the
package manager won't have to implement the full build_with_use
interface. For example, portageq currently supports a metadata
command that can be used to query installed package metadata such as
USE and IUSE. Perhaps we should use some type of interface similar
to that.
That's also a possibility. How about something like:
if [[ -n ${E_INSTALLED_PKG_METADATA_CMD} ]] ; then
${E_INSTALLED_PKG_METADATA_CMD} =cat/pkg-1.23 USE foo
else
# old vdb stuff
fi
with heavy (and checked) restrictions upon legal metadata keys (stuff
that's in individual files, not environment.bz2)?
That seems fine except it would be handy if it supports something
like the built_with_use -a and -o options since, given your
interface, it would be best to implement those on the package
manager side.
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHqrYq/ejvha5XGaMRArngAJ0SlTbooCI+5jjxesdF0MnkU0Ym6ACgsstw
5Mp+QGZPTVPGw2LyY7Cmwpk=
=8xmy
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] VDB access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: * Modify built_with_use so that it calls native_built_with_use if such a function exists, and falls back to its own implementation otherwise. * Allow package managers that implement native_built_with_use to sandbox off vdb completely, and ban all ebuild access to vdb. The problem that I see with native_built_with_use is that the package manager will then need to precisely implement the build_with_use interface along with any and all supported options (and this interface would effectively become part of the EAPI). If the package manager exposes a slightly lower level interface to the USE flags then build_with_use can use that instead, and the package manager won't have to implement the full build_with_use interface. For example, portageq currently supports a metadata command that can be used to query installed package metadata such as USE and IUSE. Perhaps we should use some type of interface similar to that. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHqNNc/ejvha5XGaMRAjseAKDQ73gjzGKR9Rdnz8o1EYxVI63v3QCgxAfA QCCmjfOLes0cZTpcPBuRCCI= =S5M6 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] VDB access
Zac Medico wrote: If the package manager exposes a slightly lower level interface to the USE flags then build_with_use can use that instead, and the package manager won't have to implement the full build_with_use interface. For example, portageq currently supports a metadata command that can be used to query installed package metadata such as USE and IUSE. Perhaps we should use some type of interface similar to that. I'd say it depends on whether we want to support native_built_with_use just as a temporary workaround until there are use deps (then just package managers not using vdb would implement it, and portage need not care), or we would want to use the general metadata query also for other purposes. Anyway, restricting ebuilds from vdb access sounds like a good idea to me. -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] VDB access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vlastimil Babka wrote: Zac Medico wrote: If the package manager exposes a slightly lower level interface to the USE flags then build_with_use can use that instead, and the package manager won't have to implement the full build_with_use interface. For example, portageq currently supports a metadata command that can be used to query installed package metadata such as USE and IUSE. Perhaps we should use some type of interface similar to that. I'd say it depends on whether we want to support native_built_with_use just as a temporary workaround until there are use deps (then just package managers not using vdb would implement it, and portage need not care), or we would want to use the general metadata query also for other purposes. The point is that if we simplify the interface and avoid duplication of logic, there will be less potential for EAPI change. If somebody wants to add a new option to built_with_use then they'll either have to bump the EAPI or just accept that anybody using an incompatible native_built_with_use implementation may experience api breakage. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHqWaf/ejvha5XGaMRAgMPAKDhVfdAcdC/m+ZCiIPUGKkeSzAZuACgr+6Y dgxIgIeV8FhsDHPxLI9egEc= =W8Pg -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
