Re: [gentoo-dev] New category: net-voip
On Thu, 20 Jul 2006 13:24:55 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Jul 20, 2006 at 08:41:46PM +0200, Kevin F. Quinn wrote: On Thu, 20 Jul 2006 00:37:47 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: On Wed, 19 Jul 2006 17:15:38 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | Things that package moves cause: | 1) Dependencies throughout the tree have to be updated And? This isn't a breakage. It is however unnecessary inconvenience for the user, even assuming the support for moves is bug-free. Think you're ignoring that proper categorization *is* useful to the user. One of the costs of that is moving when necessary. My main point is that proper categorisation is subjective. What should be in net-voip for some people, should be in net-im for others (since many packages provide functionality in both areas). Thus whether or not it moves are necessary is subjective. How often does a package lie equally across multiple categories? I think your point (pulling probably fairly close figures out of the head) is relevant to all of 100 or so packages in the tree, out of 11k. Pretty much anything in the sys-* categories, for a start. Then there's dev-libs - many packages provide libs and a simple app to use them, so where do they go? In *-libs or a category for the simple app? Sounds of it, you don't much care for categorizatin- that's fine, please keep in mind some people do find it a net gain to maintain the categorization however. I'm happy with the idea of categorisation in general, I do however think that the categorisation in the tree as it stands is simply inadequate. Examples would be lovely- numerous examples specifically. Please keep in mind the tree holds (as of about 15 hours back) 11,212 packages. Pointing at one or two packages to label all categorization as inadequate won't suffice, going to need to clear at *least* 1% of the tree to back that assertion up. I'm not going to waste time going through 11k+ packages to show you that many packages provide functionality that applies to more than one category; it seems obvious to me. Some categories are better than others - games-* for example, because those apps tend to be designed to fit a category in the first place. The problems arise when categorisation occurs in more than one direction (e.g. sys-* overlaps other categories) or when categorisation has become so tight that few packages fit only in such categories (which is what I think is happening with the net-im/voip categorisation). | 3) Binary packages go out-of-date So rebuild them. Binary packages go out of date whenever someone does a version bump too. So your opinion is that it's fine to cause users to rebuild stuff even when the package itself hasn't changed? You're ignoring what fixpackages does. Ever noticed how it's far faster when you don't have buildpkgs enabled? ;) I certainly noticed how much time is lost when fixpackages chunters through built packages to fix stuff up. My usual response to criticism of that sort applies- you know where the src is ;) My understanding is that the amount of time it takes to fix up binary packages is down to having to unpack, tweak, then re-pack - the unpack and re-pack are what consume the resource. Any alternative would involve changing the package format. Doing things *correctly* isn't always the same as doing things *fast*. Throwing correctness bits out in the name of speed is a no go (iow, fixpackages ought to be nonoptional). I agree - however this for me is an argument to avoid package moves unless the move is very necessary. Again, you may not view categories as useful, but others may. My experience with categories as they stand, is that to find a package whose location I don't already know I have to search all categories anyway - it's certainly not possible to predict in which category a package lives. Not much experience then. Your use scenario above is I'm looking for a package, not I'm trying to find packages in category x. Huh? That's my point - if I'm looking for a package I often don't know what category it is until I find it. Some categories are better than others in this respect. The point remains though that categories are one-to-one, where as many packages provide functionality in more than one area (one-to-many). You can do one-to-many in a directory structure by using links (symbolic or hard) - however CVS doesn't support them, and the dep resolver won't cope with that at the moment (it could be made to without too much trouble, I think). Of course categories don't matter to you in your case- you're not *using* them. What others are talking about how ever is
Re: [gentoo-dev] New category: net-voip
On Wed, 2006-07-19 at 17:10 +0100, Ciaran McCreesh wrote: On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Every single year quarter after quarter the more updates | that happen the slower portage is becoming. | Care to solve that? This is a minute amount of time in comparison to anything significant. If you care about Portage speed, you'd be far better off reducing the number of packages that users have installed and reducing the number of packages in the tree. | My fix would be to remove the ability to do package moves | from portage all together. Which makes me rather glad that you're not fixing anything... | |i dont think this sort of thing should hold up tree | shuffles ... | | Well it should. | | package.keywords package.use package.mask etc.. | | Where is the stability and consistency when we end up | forcing people to update /etc/portage files... Erm... Portage updates these automatically. as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. None the less I think you missed the part in the tread along time ago which Stefan said he would do the moves at the same time as bumps. Doing it that way solves most of the problems. Granted not all of them like the vdb/*DEPEND entries of other pkgs. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
Ned Ludd wrote: | Well it should. | | package.keywords package.use package.mask etc.. | | Where is the stability and consistency when we end up | forcing people to update /etc/portage files... Erm... Portage updates these automatically. as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. Err, no? You don't need to run etc-update/dispatch-conf to get those updated on package moves. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
Jakub Moc wrote: Erm... Portage updates these automatically. as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. Err, no? You don't need to run etc-update/dispatch-conf to get those updated on package moves. Err, yes. At least here you do. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites for dev-db/xmysqladmin
dev-db/xmysqladmin has no herd or maintainer, upstream hasn't made a release since 2001, and it has an open security bug [1]. It's already package.masked since about a year because of the security bug, so the removal is long overdue, and I will proceed with it in a month. An alternative, more powerful and modern GUI tool to administer MySQL databases is dev-db/mysql-administrator. [1] https://bugs.gentoo.org/show_bug.cgi?id=93792 -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[gentoo-dev] New developer: joslwah
Hi all. Joshua Ross (joslway) joined the Gentoo/PPC64 team a couple weeks ago. He'll be helping with release engineering among other things. Joshua has an extensive background in programming and different OSes going all the way back to a hex based machine. We finally managed to convince Joss to leave that machine behind and spend his time working on Gentoo instead :) Besides that Ross gives us this introduction: I'm a research mathematician with interests in linguistics. I'm a Brit., living in China, so am used to utf-8 and CJK issues. I have interests in fonts, from the usage side, as well as displaying multiple languages. I'm currently working on some projection software designed for controlling multiple projectors of differing resolution, potentially with different information. I'm married with two kids, and enjoy playing table-tennis. Welcome to the team Ross. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: joslwah
Welcome joslwah! :) On Saturday 22 July 2006 17:28, Bryan Østergaard wrote: I'm a research mathematician with interests in linguistics. I'm a Brit., living in China, so am used to utf-8 and CJK issues. Uh, fresh meat for the CJK herd and possibly for an eventual future i18n project? :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpJvbix5TwHY.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring [EMAIL PROTECTED] wrote: Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Just so we're clear, I probably will wedgie anyone who suggests trying to extend the existing tree format with N categories per pkg- sounds nice on paper, but it makes lookup a serious pita- sys-apps/portage, we'll pretend it's actually located in sys-apps, and it's also in category 'pkg-managers'. An atom states 'pkg-managers/portage'; how does a pkg manager do a lookup for it? Since the names would be aliased, either reference would be fine i.e. a dep on pkg-managers/portage would be equivalent to sys-apps/portage. If it were to be implemented with symlinks (implying one entry is real and the others are aliases) the package manager just needs to canonicalise any symlinked CPs it comes across. Since we can't have symlinks in CVS, there are other ways it can be done; first thing that pops into my head is an alias package entry in the tree, where instead of ebuilds files/ etc it would just contain a file alias with the category (and perhaps package name) of the aliased package. I would expect it to be non-trivial to implement in portage, since portage code has evolved for so long assuming that a package is in one category - I'm not saying portage code is bad, I'm just saying that much of it may have been implemented under that assumption and breaking it means testing lots of stuff. Has to walk the entire tree... so if N category per pkg is going to be proposed, need to preserve the fast lookup that's there now. I don't think the above ideas cause any substantial change to the amount of processing required. An advantage to this approach is that package moves just become aliases - existing stuff doesn't break yet you get the new categorisation as well. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Proposal for a global xinetd USE flag
Currently we have the following local xinetd USE flags. The semantics of xinetd in each case are roughly the same: dev-db/firebird:xinetd - If you want inetd version instead of a superserver (daemon) net-ftp/proftpd:xinetd - Enable support for starting from xinetd net-ftp/vsftpd:xinetd - Add support for running under xinetd net-im/bitlbee:xinetd - Install an xinetd.d file for bitlbee net-mail/qpopper:xinetd - If you want inetd version instead of standalone net-misc/linux-identd:xinetd - Use xinetd instead of the initscript net-misc/rsync:xinetd - Install an xinetd.d file for rsyncd net-proxy/ziproxy:xinetd - If you want inetd version instead of a superserver (daemon) The following ebuilds installed xinetd configuration on my machine even though I don't have xinetd installed. [EMAIL PROTECTED]:~$ equery belongs /etc/xinetd.d [ Searching for file(s) /etc/xinetd.d in *... ] dev-util/subversion-1.3.2-r1 (/etc/xinetd.d) dev-util/cvs-1.12.12-r3 (/etc/xinetd.d) net-misc/netkit-fingerd-0.17-r2 (/etc/xinetd.d) net-print/cups-1.2.1-r2 (/etc/xinetd.d) RFC. Matt -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: joslwah
Bryan Østergaard wrote: Joshua Ross (joslway) joined the Gentoo/PPC64 team a couple weeks ago. He'll be helping with release engineering among other things. [...] Welcome aboard, Joshua! :D -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
On Sat, Jul 22, 2006 at 06:04:10PM +0200, Kevin F. Quinn wrote: On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring [EMAIL PROTECTED] wrote: Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Just so we're clear, I probably will wedgie anyone who suggests trying to extend the existing tree format with N categories per pkg- sounds nice on paper, but it makes lookup a serious pita- sys-apps/portage, we'll pretend it's actually located in sys-apps, and it's also in category 'pkg-managers'. An atom states 'pkg-managers/portage'; how does a pkg manager do a lookup for it? Since the names would be aliased, either reference would be fine i.e. a dep on pkg-managers/portage would be equivalent to sys-apps/portage. If it were to be implemented with symlinks (implying one entry is real and the others are aliases) the package manager just needs to canonicalise any symlinked CPs it comes across. Since we can't have symlinks in CVS, there are other ways it can be done; first thing that pops into my head is an alias package entry in the tree, where instead of ebuilds files/ etc it would just contain a file alias with the category (and perhaps package name) of the aliased package. I would expect it to be non-trivial to implement in portage, since portage code has evolved for so long assuming that a package is in one category - I'm not saying portage code is bad, I'm just saying that much of it may have been implemented under that assumption and breaking it means testing lots of stuff. Has to walk the entire tree... so if N category per pkg is going to be proposed, need to preserve the fast lookup that's there now. I don't think the above ideas cause any substantial change to the amount of processing required. An advantage to this approach is that package moves just become aliases - existing stuff doesn't break yet you get the new categorisation as well. A disadvantage being that without a tree, your graph is broken (aliases live in the tree); this includes using strictly a bintree (remote or otherwise). Big disadvantage, hence why that approach was ignored last time it was brought up. ~harring pgpAtePs43wy7.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Sat, 22 Jul 2006 18:04:10 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | If it were to be implemented with symlinks (implying one entry is | real and the others are aliases) the package manager just needs to | canonicalise any symlinked CPs it comes across. Not that simple. Think about installed packages, overlays and changing aliases. The package manager would need to keep track of what aliases were at any given time. Then there're symlinks to outside the tree and circular symlinks... There's a lot more too it than is initially obvious. | Since we can't have symlinks in CVS, there are other ways it can be | done; first thing that pops into my head is an alias package entry | in the tree, where instead of ebuilds files/ etc it would just | contain a file alias with the category (and perhaps package name) | of the aliased package. Files are cleaner than symlinks for other reasons too. Also allows the opportunity of making 'deprecated' aliases that issue QA warnings. | Has to walk the entire tree... so if N category per pkg is going to | be proposed, need to preserve the fast lookup that's there now. | | I don't think the above ideas cause any substantial change to the | amount of processing required. Perhaps you should think. It's nowhere near as straight forward as you claim. Which is not to say it's not doable, just that it's not doable cheaply... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: joslwah
On Saturday 22 July 2006 17:28, Bryan (kloeri) wrote: Hi all. Joshua Ross (joslway) joined the Gentoo/PPC64 team a couple weeks ago. He'll be helping with release engineering among other things. Joshua has an extensive background in programming and different OSes going all the way back to a hex based machine. We finally managed to convince Joss to leave that machine behind and spend his time working on Gentoo instead :) joke *shrug* now you're screwed. ChrisWhite just told me yesterday, that we are *not* allowed to sleep or even take a nap by contract *g* (thanks Chris :P) /joke Besides that Ross gives us this introduction: I'm a research mathematician with interests in linguistics. I'm a Brit., living in China, so am used to utf-8 and CJK issues. I have interests in fonts, from the usage side, as well as displaying multiple languages. I'm currently working on some projection software designed for controlling multiple projectors of differing resolution, potentially with different information. I'm married with two kids, and enjoy playing table-tennis. Weee, another mathematician. Hopefully you'll calculate some nice things, not the bad ones :P Welcome to the team Ross. Welcome aboard Josh! :) -- Christian Heim [EMAIL PROTECTED] Gentoo Linux Developer Your friendly kernel/vserver/openvz monkey pgpjwHsfGYiGN.pgp Description: PGP signature
[gentoo-dev] Re: Einput eclass
Updated version, revised to use Gentoo supplied color codes (thanks to shillelagh for pointing me to these). http://jawed.name/dev/gentoo/einput.eclass Also cleaned up logic in displayListPrompt. Regards, John Open source, you don't pay back, you pay forward. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Naming Conventions
On Sat, 2006-22-07 at 04:43 +0900, Chris White wrote: This said, the following are recommendations: 1) Create aliases to the new functions, then at some yet-to-be-determined point, kill the aliases and bomb on the scripts (this suffers from procrastination). 2) Make an official release with the new function names and no aliases, as well as the soon to come docs. I sort of like this method because those with official portage tools can adjust their scripts, and simply alter the depend atoms for = (new API versions) and = (old versions), effectively forcing/preventing upgrades. So please, throw your .02 $currencies in on this. Chris White I could go either way with porthole. Although I have had little time to work on things lately, it would not be to hard to patch it if any names were changed. But isn't #1 what is normally done when things are deprecated in libraries (I know portage wasn't initially a library, but has become one) Just post any changes here so anyone monitoring this list can update their code accordingly. What I've done in porthole in the past is to wrap changes in a try:, except: pair to maintain functionality with either version. Although I could test the portage version and set the alias accordingly (probably better overall as well). That reminds me, I think it's time to remove a few old ones. -- Brian [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Naming Conventions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris White wrote: 1) Create aliases to the new functions, then at some yet-to-be-determined point, kill the aliases and bomb on the scripts (this suffers from procrastination). 2) Make an official release with the new function names and no aliases, as well as the soon to come docs. I sort of like this method because those with official portage tools can adjust their scripts, and simply alter the depend atoms for = (new API versions) and = (old versions), effectively forcing/preventing upgrades. I vote for #1 because it's smoother and easier (which is good for me especially because I do releases). The disruptive change proposed in #2 seems like it would cause unnecessary problems with no practical advantage over #1. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEwrPM/ejvha5XGaMRAjSNAJ9LURidl/v7MpukPFJyNKUot1qy9ACgznev td1QnRm0wxau2Ipo9v23anY= =TDgt -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Naming Conventions
On Sat, Jul 22, 2006 at 04:25:01PM -0700, Zac Medico wrote: Chris White wrote: 1) Create aliases to the new functions, then at some yet-to-be-determined point, kill the aliases and bomb on the scripts (this suffers from procrastination). 2) Make an official release with the new function names and no aliases, as well as the soon to come docs. I sort of like this method because those with official portage tools can adjust their scripts, and simply alter the depend atoms for = (new API versions) and = (old versions), effectively forcing/preventing upgrades. I vote for #1 because it's smoother and easier (which is good for me especially because I do releases). The disruptive change proposed in #2 seems like it would cause unnecessary problems with no practical advantage over #1. Suggest you mark the aliases funcs in some way in the code so that they can be spotted via scanning. Use a convience func; def alias_func(alias_name, alised_func): def f(alias_name, aliased_func, *a, **kw): import warnings warnings.warn(don't use %s, use %s % (alias_name, alias_func.__name__) return aliased_func(*a, **kw) return f pkgsplit = alias_func('pkgsplit', PkgSplit) upshot, you can puke warnings via it, and you've got something to scan the actual namespace for; makes it quite a bit easier to switch off the aliases. ~harring pgpCrN0nW5uiC.pgp Description: PGP signature
Re: [gentoo-portage-dev] Portage phase hooks patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Kelly wrote: Hello, This is that patch I had mentioned earlier on #gentoo-portage. It works by sourcing every script found in /var/libexec/portage/hooks/{pre,post}_${EBUILD_PHASE} at the appropriate time. In my case, I feel this functionality would be very useful as it allows for me to integrate my GLEP 27 implementation into portage without portage needing to worry about my implementation specifics, which may well change in later versions. I am sure there are other practical ways in which these hooks could be used. Patch at: http://soc.gentoo.org/viewcvs.py/*checkout*/glep0027/patches/portage-hooks.patch See bug# 141215. I like the idea. My main concern is that, like /etc/portage/bashrc, this creates lots of potential for foreign code to interfere with the internal workings of the ebuild environment. At a minimum, I think there should be something in the `emerge --info` output that indicates whether or not any phase hooks exist. Traditionally, configurable files that affect portage behavior go mostly in /etc/portage. I see that your intention is to make /var/libexec/portage/hooks/ a location for third-party packages to install hooks, so it makes sense to keep those separate from hooks that the user might install. I know that portage-utils currently installs a post-sync hook in /etc/portage/postsync.d/q-reinitialize, so there is some inconsistency there. We need to develop a consistent policy for appropriate locations of files like these. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEwrpF/ejvha5XGaMRAhqOAKDaSHilxUI50zsYRtyrSjgu6HfREgCdHB55 xKMmVreBNfnSymuHmUY09Q8= =fpbA -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Portage phase hooks patch
On Sat, 22 Jul 2006 16:52:38 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Kelly wrote: In my case, I feel this functionality would be very useful as it allows for me to integrate my GLEP 27 implementation into portage without portage needing to worry about my implementation specifics, which may well change in later versions. I am sure there are other practical ways in which these hooks could be used. Patch at: http://soc.gentoo.org/viewcvs.py/*checkout*/glep0027/patches/portage-hooks.patch See bug# 141215. I like the idea. My main concern is that, like /etc/portage/bashrc, this creates lots of potential for foreign code to interfere with the internal workings of the ebuild environment. At a minimum, I think there should be something in the `emerge --info` output that indicates whether or not any phase hooks exist. Traditionally, configurable files that affect portage behavior go mostly in /etc/portage. I see that your intention is to make /var/libexec/portage/hooks/ a location for third-party packages to install hooks, so it makes sense to keep those separate from hooks that the user might install. I know that portage-utils currently installs a post-sync hook in /etc/portage/postsync.d/q-reinitialize, so there is some inconsistency there. We need to develop a consistent policy for appropriate locations of files like these. I still think that those hooks should go into the tree rather than being installed by packages. That's mainly so they get increased visibility and gives us (us being Gentoo, not just Portage) more access and control over them, like we have with eclasses. This also moves responsibility from hook authors to pkgmanager authors (the package mamanger has to support the hook format in the tree, not the hook has to support (all of) the specific package manager hook formats). I know Mike has taken care of Paludis support already, but look at a larger scale: a) n hook authors supporting m package manager interfaces: O(n*m) b) n hook authors and m package managers supoprting one repository interface: O(n+m) Also with a) you have to play what I call the catch up game, e.g. a new package manager gets out and all hooks have to account for a new interface (even if it's just a new path). Of course a) has the drawback that it requires a solid spec of the interface, but that's something we want anyway. However, *if* they are going to be installed by packages they should go either into /etc/portage/foobar or /usr/lib/portage/foobar (like any 3rd party elog or cache modules), foobar being something we'd have to decide on. The suggested /var/libexec/portage has several issues: - /var/libexec is AFAIK not defined by FHS - executable data doesn't belong in /var unless it's application data which isn't the case here - libexec generally sucks (even in /usr), especially as we already use /usr/lib for what generally goes there (support scripts) Independent on the location I'd like to see the ability to blacklist individual hooks for testing, troubleshooting, debugging and probably a few other reasons. And no, this should not be done with $FEATURES ;) Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [RFC] Naming Conventions
On Sat, 22 Jul 2006 16:25:01 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris White wrote: 1) Create aliases to the new functions, then at some yet-to-be-determined point, kill the aliases and bomb on the scripts (this suffers from procrastination). 2) Make an official release with the new function names and no aliases, as well as the soon to come docs. I sort of like this method because those with official portage tools can adjust their scripts, and simply alter the depend atoms for = (new API versions) and = (old versions), effectively forcing/preventing upgrades. I vote for #1 because it's smoother and easier (which is good for me especially because I do releases). The disruptive change proposed in #2 seems like it would cause unnecessary problems with no practical advantage over #1. combination of both. Phase one: change function names and add aliases Phase two: make the aliases generate warnings Phase three: drop the aliases Maybe combine phases one and two. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature