Re: [gentoo-dev] New category: net-voip

2006-07-22 Thread Kevin F. Quinn
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

2006-07-22 Thread Ned Ludd
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

2006-07-22 Thread Jakub Moc
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

2006-07-22 Thread Simon Stelling
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

2006-07-22 Thread Luca Longinotti
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

2006-07-22 Thread Bryan Ãstergaard
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

2006-07-22 Thread Diego 'Flameeyes' Pettenò
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

2006-07-22 Thread Kevin F. Quinn
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

2006-07-22 Thread Matthew Kennedy
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

2006-07-22 Thread Peter Gordon

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

2006-07-22 Thread Brian Harring
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

2006-07-22 Thread Ciaran McCreesh
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

2006-07-22 Thread Christian Heim
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

2006-07-22 Thread John Jawed

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

2006-07-22 Thread Brian
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

2006-07-22 Thread Zac Medico
-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

2006-07-22 Thread Brian Harring
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

2006-07-22 Thread Zac Medico
-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

2006-07-22 Thread Marius Mauch
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

2006-07-22 Thread Marius Mauch
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