[gentoo-dev] Re: ecompress heads up
Mike Frysinger [EMAIL PROTECTED]: the new version of portage has customizable compression ... this is cool as now people can do bzip/gzip/whatever Auto compressing is nice, but I have a question for info files. The /usr/share/info/package/dir file must not be compressed but is with newer versions. As I read in a bug [1], packages should not install dir files, so what is the best solution here? Does Portage create the dir file? Should I remove it from the sandbox image? V-Li [1] URL:http://bugs.gentoo.org/show_bug.cgi?id=82933 signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On 2007-01-30, Matthias Langer [EMAIL PROTECTED] wrote: nope ... let's hope c++-0x comes out soon and that compiler vendors are faster in implementing it than c++-98. It's actually officially called (skipping all the admin stuff): C++09 That gives a good indication of when it is likely to come out (at the earliest) :-) And, of course, the whole of this discussion is equally applicable for TR2. phil -- change name before @ to phil for email -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] KDE herd hurting for help
Hi, Unfortunately, most of the active KDE herd/group members are a bit unactive right now (self included), which means that bugs are really starting to pile up. If you have any interest in this at all, please by all means join the herd and start helping us out. Thanks! Caleb -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] KDE herd hurting for help
DITTO, I'm currently only available on weekends, so guys, come kill some bugs for us ;-) On 1/31/07, Caleb Tennis [EMAIL PROTECTED] wrote: Unfortunately, most of the active KDE herd/group members are a bit unactive right now (self included), which means that bugs are really starting to pile up. If you have any interest in this at all, please by all means join the herd and start helping us out. -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] KDE herd hurting for help
Hi, I'm not a Gentoo dev at all, but I'll try to kill as much KDE bugs as possible. .. currently working on bug#163051 Regards, Elias P. Original-Nachricht Datum: Wed, 31 Jan 2007 14:43:57 +0100 Von: Ioannis Aslanidis [EMAIL PROTECTED] An: gentoo-dev@lists.gentoo.org Betreff: Re: [gentoo-dev] KDE herd hurting for help DITTO, I'm currently only available on weekends, so guys, come kill some bugs for us ;-) On 1/31/07, Caleb Tennis [EMAIL PROTECTED] wrote: Unfortunately, most of the active KDE herd/group members are a bit unactive right now (self included), which means that bugs are really starting to pile up. If you have any interest in this at all, please by all means join the herd and start helping us out. -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Dropping keywords is bad, m'kay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apparently people are starting to drop arch keywords again without notifying arch teams in any way, shape or form. As the developer handbook indicates, it is greatly appreciated and makes for much smoother workings with the arch teams if you'd at least give us a bug indicating why you felt the need to drop our keywords from a revision or version bump of a package. Not to be a hard ass, but repeat offenders will be reported to both the QA and DevRel teams. Cheers, - -- Jason Wever Gentoo/Sparc Team Co-Lead -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFwLlrdKvgdVioq28RAqgYAJ0VOVtZPE1LB2GGuknZDmypoZ71wQCffU+N 6/rZ/KbL6XuVA1yMQUtWGT4= =RlIA -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] make_desktop_entry in eutils.eclass
Mike Frysinger wrote:
On Tuesday 30 January 2007 16:10, Jim Ramsay wrote:
In other words, I propose that this function should probably do
'basename' on $exec before using it for the .desktop filename.
no ... the point of using $exec is to make sure the .desktop file is unique
i'll change it to sanitize the filename and turn them into underscores
Sure, but the name is already based on $exec AND ${PN} (and
SLOT too if SLOT != 0), so the uniqueness is already guaranteed
per-package, it would just be a matter of the package maintainer not
using the same exec twice in the same package, which probably
wouldn't even happen anyway. I still think basename would be
sufficient.
I propose an optional environment variable an ebuild can set before
calling make_desktop_entry, called DESKTOP_BASENAME, which would be
the basename of the file (not including the .desktop suffix) that the
function would use (if set) to create the file.
env vars to functions are lame
In that case it could be another optional parameter instead.
3 - Allow me to add other important settings like 'NoDisplay',
'OnlyShowIn', and/or 'MimeType'.
at this point, you might as well write your own .desktop file
Personally I'd rather just add one line to my ebuild as opposed to
creating and maintaining a .desktop file in the files directory. This
would just add a useful feature for those who want that level of
flexibility.
--
Jim Ramsay
Gentoo/Linux Developer (rox)
signature.asc
Description: PGP signature
Re: [gentoo-dev] KDE herd hurting for help
Hi folks. I'm new here, so thought I'd say hello. On Wednesday 31 January 2007 13:07, Caleb Tennis wrote: Unfortunately, most of the active KDE herd/group members are a bit unactive right now (self included), which means that bugs are really starting to pile up. If you have any interest in this at all, please by all means join the herd and start helping us out. Well, I'm a big fan of Gentoo ever since discovering it last year (moved over from SuSE, via a quick detour chez Kubuntu). I also use KDE and am a decent coder, so this looks like a place to start helping out. I'll get reading the developer handbook and hope to be in touch soon! Cheers, Pete. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 11:11:20 -0500 (EST) Caleb Tennis
[EMAIL PROTECTED] wrote:
| * Hard dep upon boost. This sucks for g++-4.1 users.
|
| * Hard dep upon g++-4.1, which isn't available for all archs. This
| doesn't even work because there's no guarantee that =4.1 is being
| used even if it's installed.
|
| I don't think these are necessarily compatible. tr1 is implemented
| in the std::tr1, while I think everything in boost is just in the
| boost namespace (unless this has changed since I've used boost).
| This would mean that the project code itself would have to have the
| logic to decide which set of headers to use. I'm guessing most
| probably won't have the compatibility code to make that accessment,
| though some may.
Everything I've seen that uses tr1 can also use boost. The
compatibility code is just something like:
#include boost/shared_ptr.hpp
namespace std
{
namespace tr1
{
using boost::shared_ptr;
using boost::enable_shared_from_this;
using boost::static_pointer_cast;
// and anything else that's necessary
}
}
It's not exactly difficult to do...
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 10:47:09 -0600 Grant Goodyear [EMAIL PROTECTED] wrote: | * Hard dep upon g++-4.1, which isn't available for all archs. This | doesn't even work because there's no guarantee that =4.1 is being | used even if it's installed. | | I haven't done my homework, so I'll just ask: Is there a reasonable | timeframe for 4.1 on archs that we're using? Is there actual evidence | that tr1-using packages are going to become prevalent before 4.1+ | becomes ubiquitous? A few archs are having pretty big issues with 4.1. In the mean time, tr1 is so damned useful that programmers are going to take a lot of persuading *not* to use it. | An alternative, which would be a real pain, is to have g++-4.1 | ebuilds build boost tr1 libraries as part of the ebuild, and then | have compatibility libraries for people who remove old versions of | g++, just like we do now. The benefit would be that at the cost of | forcing everybody to upgrade g++ we could rely on tr1 existing | everywhere. Even that won't necessarily work, since g++-4.1 doesn't include a full tr1 implementation. It includes the useful stuff, but it's missing the random number and regex parts of the specification -- which, fortunately, are nowhere near as popular as hash tables and smart pointers. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] KDE herd hurting for help
We'd be rather more interested if you overlook a little that part and help us fix a few bugs ;) Peter Lewis wrote: Hi folks. I'm new here, so thought I'd say hello. On Wednesday 31 January 2007 13:07, Caleb Tennis wrote: Unfortunately, most of the active KDE herd/group members are a bit unactive right now (self included), which means that bugs are really starting to pile up. If you have any interest in this at all, please by all means join the herd and start helping us out. Well, I'm a big fan of Gentoo ever since discovering it last year (moved over from SuSE, via a quick detour chez Kubuntu). I also use KDE and am a decent coder, so this looks like a place to start helping out. I'll get reading the developer handbook and hope to be in touch soon! Cheers, Pete. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
Ciaran McCreesh a écrit : * Hard dep upon boost. This sucks for g++-4.1 users. * Hard dep upon g++-4.1, which isn't available for all archs. This doesn't even work because there's no guarantee that =4.1 is being used even if it's installed. * || ( ) deps, and hope that if the user has 4.1 installed then they're using it. Since library implementations aren't runtime switchable, this will lead to breakages if users upgrade gcc and then remove boost. None of these are particularly nice... Newbie idea : g++ and boost both provide virtual/tr1 Newbie question : besides the fact that you would have to rebuild packages if you changed the virtual, is there anything painfully obvious why that would be a bad idea ? Just a thought :) Rémi -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 23:36:33 +0100 Rémi Cardona [EMAIL PROTECTED] wrote: Newbie idea : g++ and boost both provide virtual/tr1 Newbie question : besides the fact that you would have to rebuild packages if you changed the virtual, is there anything painfully obvious why that would be a bad idea ? And what exactly is required of a package providing virtual/tr1? If it has to implement the entirity of the TR, then g++-4.1 can't provide the virtual and the purpose is lost since the most used parts of the extension will be those provided by GCC. If, on the other hand, you require the virtual to provide only the parts currently implemented in g++, what happens in the future for packages that require other parts of the tr1 extension? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 23:24:31 + Stephen Bennett [EMAIL PROTECTED] wrote: | And what exactly is required of a package providing virtual/tr1? If it | has to implement the entirity of the TR, then g++-4.1 can't provide | the virtual and the purpose is lost since the most used parts of the | extension will be those provided by GCC. If, on the other hand, you | require the virtual to provide only the parts currently implemented in | g++, what happens in the future for packages that require other parts | of the tr1 extension? Mmm. Well... virtual/tr1-memory virtual/tr1-unordered-containers virtual/tr1-random virtual/tr1-regex Rather a lot of work, and rather icky... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Wed, Jan 31, 2007 at 11:24:31PM +, Stephen Bennett wrote: On Wed, 31 Jan 2007 23:36:33 +0100 Rémi Cardona [EMAIL PROTECTED] wrote: Newbie idea : g++ and boost both provide virtual/tr1 Newbie question : besides the fact that you would have to rebuild packages if you changed the virtual, is there anything painfully obvious why that would be a bad idea ? And what exactly is required of a package providing virtual/tr1? If it has to implement the entirity of the TR, then g++-4.1 can't provide the virtual and the purpose is lost since the most used parts of the extension will be those provided by GCC. You're ignoring that new style virtuals can have versions; thus virtual/tr-[arbitrary version 1] can be 'almost full 1 support'. Yes, mildly hackish, but it address that concern. As for whatever I build against, I hard RDEP on, as said elsewhere, need a way to specify that an rdep is 'binding', non changable. ~harring pgpPz9cjol1cf.pgp Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 15:32:03 -0800 Brian Harring [EMAIL PROTECTED] wrote: | You're ignoring that new style virtuals can have versions; thus | virtual/tr-[arbitrary version 1] | can be 'almost full 1 support'. Which means what, in terms of parts of tr1 that are and aren't supplied by various people? There's no nice neat linear progression there, beyond most things requiring a few of the new basic utilities. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Wed, Jan 31, 2007 at 11:38:04PM +, Ciaran McCreesh wrote: On Wed, 31 Jan 2007 15:32:03 -0800 Brian Harring [EMAIL PROTECTED] wrote: | You're ignoring that new style virtuals can have versions; thus | virtual/tr-[arbitrary version 1] | can be 'almost full 1 support'. Which means what, in terms of parts of tr1 that are and aren't supplied by various people? There's no nice neat linear progression there, beyond most things requiring a few of the new basic utilities. The linear progression would be made up as you go- admittedly, if a third provider shows up, scheme goes to hell. Don't claim it's the best notion, but it's definitely a fallback option assuming nothing decent is found. ~harring pgpLPIA0g6qwv.pgp Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Wed, 31 Jan 2007 16:00:49 -0800 Brian Harring [EMAIL PROTECTED] wrote: | On Wed, Jan 31, 2007 at 11:38:04PM +, Ciaran McCreesh wrote: | On Wed, 31 Jan 2007 15:32:03 -0800 Brian Harring | [EMAIL PROTECTED] wrote: | | You're ignoring that new style virtuals can have versions; thus | | virtual/tr-[arbitrary version 1] | | can be 'almost full 1 support'. | | Which means what, in terms of parts of tr1 that are and aren't | supplied by various people? There's no nice neat linear progression | there, beyond most things requiring a few of the new basic | utilities. | | The linear progression would be made up as you go- admittedly, if a | third provider shows up, scheme goes to hell. A third provider like STLport or icc? STLport already supports tr1 hash tables... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
[gentoo-dev] [treecleaner] package removals
media-video/dxr2-driver has been removed from the tree See http://bugs.gentoo.org/show_bug.cgi?id=153365 Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] make_desktop_entry in eutils.eclass
On Wednesday 31 January 2007, Jim Ramsay wrote: Personally I'd rather just add one line to my ebuild as opposed to creating and maintaining a .desktop file in the files directory. This would just add a useful feature for those who want that level of flexibility. which is rarely needed/wanted i could add an option for every single aspect of the .desktop file spec but in reality, you have to draw the line somewhere the items you requested, while useful, are not nearly common enough to warrant attention on any scale about the only thing that'd work is an additional parameter called cruft that'd be passed unfiltered into the .desktop file -mike pgp8RYgO4Auwm.pgp Description: PGP signature
Re: [gentoo-dev] Re: ecompress heads up
On Thursday 01 February 2007, Zac Medico wrote: Portage does create the dir files for each of the directories listed in the INFOPATH and INFODIR environment variables. it should be removing the dir files in install_qa_check() from /usr/share/info/ -mike pgpWQ95qQaZY2.pgp Description: PGP signature
[gentoo-dev] eclass proposal - savedconfig.eclass
Fellow devs,
Many packages have far more options than are presented to gentoo users though
an ebuild interface. By embracing the principles of choice[1] the gentoo
developers have an obligation to provide a far range of choice on their
installation. This is particularly important in:
- embedded applications - where size matters
- secure configuration - minimal feature install to reduce risk caused by zero
day vulnerabilities
- hardware support - lots of hardware drivers in the same package and a user
will only wants one or small number of them
- customisation for your hardware - compile time memory guidelines/limits
- customisation because, after all, thats why the upstream put it there!
Ebuilds that already have their implementation of savedconfig:
sys-apps/busybox
sys-libs/uclibc
x11-wm/dwm
x11-misc/dmenu
Other potential candidates:
net-misc/dropbear [2]
app-emulation/mol
app-shells/tcsh
dev-libs/klibc
dev-lang/ccc
mail-mta/sendmail
net-dialup/isdn4k-utils
net-im/kadu
net-irc/cyclone
net-wireless/wpa_supplicant
sys-boot/netboot
sys-libs/uclibc++
www-apache/mod_*
net-misc/asterisk
net-misc/zaptel
dev-lang/php
The savedconfig configuration control aims:
- provide user with with choices where they make a difference
- provide a single point for configuration editing
- reduce developer effort by supporting every option available without packing
an ebuild full of USE flags
- reduce USE flag bloat where no dependencies are affected
- limit the mass use of USE_EXPAND
The savedconfig configuration control does NOT aim to:
- replace the USE flag determination of dependencies
- provide an interface to options where there is only a small number of
options
- replace global USE flags that have ebuild purpose
IMPLEMENTION
In keeping with existing convention /etc/portage/savedconfig seems to be the
logical choice as to where to store configuration. It has CONFIG_PROTECT and
is close to the package.uses files (where other configuration control exists).
INTERFACE:
A user that wishes to customise a particular package will:
1. Emerge the package to obtain the default configuration (I can see how this
could be generally avoided)
2. Edit the saved configuration in /etc/portage/savedconfig/${CATEGORY}/${PF}
3. adds ${CATEGORY}/${P*} savedconfig -* atom to /etc/portage/package.uses.
(configuration controlling USE flags should be omitted)
4. Reemerge the package
By default packages that have the option of restoring a saved config will,
without specific USE flags or options, store their config.
ECLASS INTERFACES
STORE_CONFIG
store_config -s name1,name2,name3 (file/directory)..
Stores the specific file(s)/directory(ies) in the directory
${D}/etc/portage/savedconfig/${CATEGORY}/${PF}/
If a single file is the only arguement then the file is copied to
${D}/etc/portage/savedconfig/${CATEGORY}/${PF}
store_config should only be called from pkg_preinst or src_install
Also creates the following symlinks to it
/etc/portage/savedconfig/${CATEGORY}/${P}
/etc/portage/savedconfig/${CATEGORY}/${PN}-$(get_version_component_range 1-x)
/etc/portage/savedconfig/${CATEGORY}/${PN}-$(get_version_component_range
1-(x-1))
..
..
/etc/portage/savedconfig/${CATEGORY}/${PN}
As some packages, like uclibc, have regular cross compile functionality which
require separate config files for each host. This can be achieved with the -s
option.
store_config -s ${CTARGET},${CHOST} .config
will copy .config to:
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${P}
and create the following symlinks:
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${P}
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}-$(get_version_component_range
1-x)
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}-$(get_version_component_range
1-x)
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}-$(get_version_component_range
1-(x-1))
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}-$(get_version_component_range
1-(x-1))
..
..
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}
Q1 I'm open to suggestion that all CTARGETS should occur before CHOSTS
Baselevel symlinks, /etc/portage/savedconfig/${CATEGORY}/... can occur if you
specify a empty -s name using an extra comma i.e.
save_config -s ${CTARGET},${CHOST}, .config
RESTORE_CONFIG
restore_config -s name1,name2... (file/directory)
Restores the config from the closest match from above (in same order) *IF*
USE=savedconfig.
restore_config should be called in src_unpack or src_compile after any
competing USE flags have been selected.
store_config and restore config should have the same arguements.
[1] http://www.gentoo.org/foundation/en/#doc_chap2
[2] https://bugs.gentoo.org/show_bug.cgi?id=158185
If the -s option is used the config files are restored in the same order
listed in save_config with the -s.
WARN_CONFIG
warn_config (useflags)
warns the user that the useflags have been overridden by savedconfig
Anything
Re: [gentoo-dev] make_desktop_entry in eutils.eclass
On Wed, 31 Jan 2007 23:30:53 -0500, Mike Frysinger [EMAIL PROTECTED]
wrote:
about the only thing that'd work is an additional parameter called
cruft that'd be passed unfiltered into the .desktop file
You can also imagine a -v switch, which would make this function print
the full path (with its $D prefix) of the file.desktop it has created.
This way, people could do:
src_install() {
...
local desktop_file=$(make_desktop_entry -v ...) || die
echo MimeType=... ${desktop_file}
...
}
I don't say this solution is better than the cruft parameter though,
it's really a matter of taste.
--
TGL.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclass proposal - savedconfig.eclass
On Thursday 01 February 2007, Daniel Black wrote: IMPLEMENTION thanks for putting this together store_config should only be called from pkg_preinst or src_install this is easy to check in the eclass via $EBUILD_PHASE Also creates the following symlinks to it i dont see much value in these symlinks ... what do they gain us ? As some packages, like uclibc, have regular cross compile functionality which require separate config files for each host. This can be achieved with the -s option. i dont think the ebuild should care whether it's being cross-compiled ... any package should be cross-compilable so the ebuild should really be agnostic in other words, the search path for the .config should always check $CTARGET subdirs followed by $CHOST followed by the normal $CATEGORY -mike pgp1zvhJxgFTx.pgp Description: PGP signature
Re: [gentoo-dev] eclass proposal - savedconfig.eclass
On Thu, Feb 01, 2007 at 06:21:01PM +1100, Daniel Black wrote: Fellow devs, WARN_CONFIG warn_config (useflags) warns the user that the useflags have been overridden by savedconfig Anything else? overriding use flags by a secondary configuration is a mess waiting to happen... needs actual integration in some fashion imo, rather then well... you probably should define it in both since it may ignore it. Goes without saying, ignoring manager forced use configuration also means crap/missing deps are thus possible... Feel free to clarify that little snippet ;) ~harring pgpxFLGaPwuL2.pgp Description: PGP signature
Re: [gentoo-portage-dev] [RFC] Depending on active version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin F. Quinn wrote: On a general note, introducing dynamic dependencies into the depgraph worries me, although I'm not sure I can articulate why. Can you articulate metadata cache? :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwJf8tbrAj05h3oQRAgmCAJ4gYozwZqYL8f2Qi3mLx+cE9G4shwCeNnhM +n+IOpU9vuEw7g7xkSLHEi0= =d+dS -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
On Tue, 30 Jan 2007 17:06:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied Given that in the general case the package manager can't change the active provider and will have to bail with an appropriate message that the user needs to change it themselves, the obvious solution to this is the previously-discussed-somewhere-I-can't-remember ebuild function, called on depgraph creation, to check that it will be able to compile in the current system environment. It's considerably simpler and more generally useful than subverting DEPEND to add weird special-case hacks to it. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
Stephen Bennett wrote: On Tue, 30 Jan 2007 17:06:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied Given that in the general case the package manager can't change the active provider and will have to bail with an appropriate message that the user needs to change it themselves, the obvious solution to this is the previously-discussed-somewhere-I-can't-remember ebuild function, called on depgraph creation, to check that it will be able to compile in the current system environment. It's considerably simpler and more generally useful than subverting DEPEND to add weird special-case hacks to it. No one said subverting DEPEND was necessarily required. This stuff is essentially another visibility filter. Think for example along the ACCEPT_RESTRICT lines, but less fugly. User has FEATURES=sandbox ebuild has RESTRICT=sandbox Ebuild is not visible because it is incompatable with current environment. The only problem here being some visibility filters are 'soft' (like sandbox and USE vars) and some filters are hard (dependencies). USE flags can often be flippy flopped to get a solution (as with sandbox, which can be selectively turned off). -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
On Wed, 31 Jan 2007 12:27:10 -0500
Alec Warner [EMAIL PROTECTED] wrote:
Hmm; one could get the same benefit by introducing a new interface
(e.g. pkg_env_check()) which is defined to return true if the
environment is ok, false otherwise (with some text to stdout,
perhaps). The package manager would then run this function, after
building the depgraph and finding the candidate packages to merge,
for each candidate package - if any package fails is env_check,
none of the packages get emerged. Note this is then completely
independent of depgraph creation.
In the 'tr1' example, I'd imagine something like this:
use.local.desc: boost: Use boost library for tr1 rather than gcc's.
ebuild:
...
inherit ... toolchain-funcs versionator ...
...
DEPEND=... boost? ( dev-libs/boost ) ...
...
pkg_env_check() {
use boost return 0
version_is_at_least 4.1 $(gcc-version) return 0
echo Either USE boost, or switch to gcc later than 4.1
}
(with a default definition, pkg_env_check() { return 0; } )
In an ideal system you'd want this stuff in the metadata cache so that
the resolver can deal with it up front.
You're talking about the metadata on the host, rather than the stuff on
the rsync servers? I'm not sure you could cache the results even on
the host - you would need to know what could affect the results so as
to know when the cached information is out of date and has to be
recalculated. That would either have to checked on every emerge, or
made a separate switch (i.e. rely on the user to tell emerge when the
environment has changed).
All resolution is a brute
force metadata search; and assuming we had all the necessary data up
front, we can optimize the search there (see pkgcore and restriction
subsystem) versus IMHO doing a 'dumb' search and then running through
a list of criteria for inclusion.
This is the same reason why built_with_use in pkg_setup is really just
use_deps; these metadata should be included during resolution, not
after.
My concern about dynamic dependencies runs to use deps, as well :)
One could consider use-deps to be a special case of Marius' active
checks. how pkg P was built isn't so different from slot S of P is
active in terms of dep-graph creation; both are asking about the
state of host target systems, rather than the tree.
In the case of USE deps, things are saner because the data doesn't
change without the package manager knowing about it. Effectively the
depgraph becomes static w.r.t. the tree + installation record (rather
than just static w.r.t. the tree). With active checks implemented in
the depgraph, however, that is no longer the case - the depgraph can
change independently of the tree and the installation record.
With that said, I'm not sure how easy it would be to rewrite that
code; and this is simpler in that it's just a few bash functions as
opposed to more resolver foo.
There's a lot to be said for keeping things simple, of course :) It's
easy enough to mess up things like dep-graphs in any case - introducing
these sorts of dynamic dependencies can render it substantially more
complex.
Another way to look at it, is to consider how often this sort of thing
comes up. My understanding is that it is relatively rare; across the
10,000+ packages in the tree only a handful use 'built_with_use' fex.
That makes a strong case for having a simple solution in the near term,
and re-visit if it becomes commonplace.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [RFC] Depending on active version
Kevin F. Quinn wrote:
On Wed, 31 Jan 2007 12:27:10 -0500
Alec Warner [EMAIL PROTECTED] wrote:
Hmm; one could get the same benefit by introducing a new interface
(e.g. pkg_env_check()) which is defined to return true if the
environment is ok, false otherwise (with some text to stdout,
perhaps). The package manager would then run this function, after
building the depgraph and finding the candidate packages to merge,
for each candidate package - if any package fails is env_check,
none of the packages get emerged. Note this is then completely
independent of depgraph creation.
In the 'tr1' example, I'd imagine something like this:
use.local.desc: boost: Use boost library for tr1 rather than gcc's.
ebuild:
...
inherit ... toolchain-funcs versionator ...
...
DEPEND=... boost? ( dev-libs/boost ) ...
...
pkg_env_check() {
use boost return 0
version_is_at_least 4.1 $(gcc-version) return 0
echo Either USE boost, or switch to gcc later than 4.1
}
(with a default definition, pkg_env_check() { return 0; } )
In an ideal system you'd want this stuff in the metadata cache so that
the resolver can deal with it up front.
You're talking about the metadata on the host, rather than the stuff on
the rsync servers? I'm not sure you could cache the results even on
the host - you would need to know what could affect the results so as
to know when the cached information is out of date and has to be
recalculated. That would either have to checked on every emerge, or
made a separate switch (i.e. rely on the user to tell emerge when the
environment has changed).
I am talking about the host yeah; cache was a bad term on my part;
obviously you cannot cache stuff like this.
My concern about dynamic dependencies runs to use deps, as well :)
One could consider use-deps to be a special case of Marius' active
checks. how pkg P was built isn't so different from slot S of P is
active in terms of dep-graph creation; both are asking about the
state of host target systems, rather than the tree.
In the case of USE deps, things are saner because the data doesn't
change without the package manager knowing about it. Effectively the
depgraph becomes static w.r.t. the tree + installation record (rather
than just static w.r.t. the tree). With active checks implemented in
the depgraph, however, that is no longer the case - the depgraph can
change independently of the tree and the installation record.
I am unsure how fast these types of checks would or could be. I mean we
can add arbitrary key caching and arbitrary key matching, but then that
grows the cache substantially and probably slows down dependency
resolution. As you stated, some things just can't be cached properly
and still have value.
With that said, I'm not sure how easy it would be to rewrite that
code; and this is simpler in that it's just a few bash functions as
opposed to more resolver foo.
There's a lot to be said for keeping things simple, of course :) It's
easy enough to mess up things like dep-graphs in any case - introducing
these sorts of dynamic dependencies can render it substantially more
complex.
I think the complexity exists already though; currently we are just
hiding it, requiring people to find workarounds in an otherwise complex
playground of building packages.
Another way to look at it, is to consider how often this sort of thing
comes up. My understanding is that it is relatively rare; across the
10,000+ packages in the tree only a handful use 'built_with_use' fex.
That makes a strong case for having a simple solution in the near term,
and re-visit if it becomes commonplace.
I think your understanding is off then. A quick grep (qrep -H
built_with_use | wc -l) gives me 814 calls to 'built_with_use' (qgrep is
in portage-utils).
If you grep through eclasses you will also see 53 separate calls; so you
can imagine what the real usage could be (definately at least 1/20th the
tree, not something I'd call minor).
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on active version
On Wed, 31 Jan 2007 17:47:26 + Stephen Bennett [EMAIL PROTECTED] wrote: On Tue, 30 Jan 2007 17:06:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The idea is to add a special category (let's call it active for now) that has the following properties: - this category doesn't exist in portdir or vdb (= no ebuilds) - when portage ($pkgmanager) encounters a active/foo atom in a dependency string it executes some special code (e.g. $PORTDIR/scripts/active-check/foo =active/foo-1) to determine if that atom is satisfied Given that in the general case the package manager can't change the active provider and will have to bail with an appropriate message that the user needs to change it themselves, the obvious solution to this is the previously-discussed-somewhere-I-can't-remember ebuild function, called on depgraph creation, to check that it will be able to compile in the current system environment. It's considerably simpler and more generally useful than subverting DEPEND to add weird special-case hacks to it. Yeah, thinking about it I have to agree tat generic dep_check() support (to give the thing a name) would be a better solution here. Marius -- gentoo-portage-dev@gentoo.org mailing list
