[gentoo-dev] Re: new categories:
Denis Dupeyron wrote: On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov geo...@gentoo.org wrote: Besides, in my opinion, the ability to see what's there in at least minimally categorized way without having to resort to using some special tools or going to some website is worht something. In this vain I was proposing going the opposite direction - to allow arbitrary nesting of categories, like going sci-math - sci/math and deeper (then packages would naturally be specified by FQEN - fully qualified ebuild names). Its not like tree walker would be the most complex part of code in portage.. Actually we'd want both tags and nesting. They don't address the same issue. Arbitrary nesting of categories allows better management and storing of ebuilds. It could also allow a meta-ebuild to depend on a whole subcategory to ease maintenance of said meta-ebuild. It's more a developer's feature. That sounds very similar to sets? Sorry if I'm missing something obvious, but I thought sets were used with kde4; if they are unavailable to the ebuild author, perhaps a suitably-defined extension (for in-tree sets) might be useful? The obvious advantage being that they are not tied to a specific category, ofc; could you expand a bit on 'better management and storing'? Tags allow ebuilds to appear as being pertinent to more (sub-)categories than just the one they're stored into. It may help some of us locate packages they need in a better and/or faster way. It's more of a user's feature. Tags sound cool. I'm opposed to losing the current single flat category schema, fwtw, unless it enables something majorly-useful. It's *way* better than other distros (I am deadset against losing all categorisation) and still nice and immediate.
[gentoo-dev] Re: Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Ben de Groot wrote: Jeremy Olexa wrote: Andrey Grozin wrote: It was discussed (don't have a reference to the thread at hand) that it would be useful to have a table which shows which functions die by themselves, and which not. I see this asked every X months and never quite figured out why, (this isn't personal against you, Andrey) [...] Take a look for yourself and you will see why there has never been a table or anything created. (it is trivial - and you have the source on your computer already) That's more an argument for putting the table on the web than continuing without adequate documentation. If it's going to change, automate it using the script you posted (assuming it's watertight.) It shouldn't be necessary to grep the source Agreed.
[gentoo-dev] Re: [v4] Planning for automatic assignment computation of bugs
Peter Volkov wrote: ? ???, 04/01/2009 ? 18:57 +0100, Robert Buchholz ?: Accepting the fact that different teams have different preferences, we need to find a solution for them to set theirs individually. This could either be the order of elements in metadata.xml (and would set the preference on a per-package basis) or some attribute in herds.xml (which would be a global setting per herd, and we'd need to find a default). It looks like we really need some per-team configuration for default assignment. I agree, given that it's not going to affect running systems (I hope); in the longer term, it would be nice to be able to configure by pkg, cat or herd. Probably it's good idea to add 'weight' (or 'nice') attribute for herd and maintainer elements both in herds.xml and metadata.xml. Bug assignment field will be selected from the elements with minimal weight (least nice ;)). Shouldn't the 'nicest' entity take it? ;) A simple assignToHerd=yes|no|unset (or 0|1) might be easier to deal with (otherwise you're going to have a maintenance headache with the variant levels?) and would deal with all the use-cases afaict; a team does [eg kde/gnome] or does not want bugs, unless the category/CP/CPV merits a change in that policy. Obviously if none set, use the maintainer list as-is without filtering. Sure, it can be done by patching the tree over time, but it seems crude and a further maintenance + bug-wrangling burden for no benefit, when the coders are on-hand and engaged to tweak the new impl. OFC, a rush to completion is understandable, given how long this has been in the planning; I'd argue that's a reason to go the final ten metres.
[gentoo-dev] Re: Re: bash version in ebuilds/eclasses...non-compliance and what to do?
Fabian Groffen wrote: On 20-12-2008 05:35:25 +, Steve Long wrote: I note that bash-3.2_p17-r1 is stable on all the architectures that 3.0-r12 lists (it just adds the two -fbsd archs as unstable.) portage-2.1.4.5 requires at least that version (only unstable on mips as against 2.1.1-r2) It might be worth skipping to 3.2, since that would simplify regex handling. The only problem we have there is that bash-3.2.17 only comes in patches on top of 3.2. During bootstrap that's problematic, as gnu patch (or any other patch) might not be available, or simply b0rked. For that reason we bootstrap with a portage pre SVN revision 10460, which does not require =3.2.17. See http://bugs.gentoo.org/show_bug.cgi?id=229677#c11 on why PMS should require 3.2.17 over plain 3.2 if you decide to push the requirement update. Yeah, that sounds great. Believe me I ran into troubles with early 3.2 ;) which is why I'm deadset against unstable across the board. Regex handling within BASH is quite important eg on cygwin where process creation is expensive. While I'm happy keeping my scripts compatible across 3.x (they're not Gentoo-specific) ebuild syntax would be much more perl-like if we were on 3.2.17+ (and would thus hold less gotchas for people new to the format, as well as perhaps giving some old hands a bit of new shiny;) We can work around it by using a self-made pre-patched tarball, though. Indeed, and they can be pushed out to stages pretty painlessly. If metro is politically unacceptable, I'm sure releng could do it with catalyst; somehow I doubt it's as hard to bootstrap as perl, but please don't flame me if you have something to say; just _add_ something technical. Happy Holidays to all those whom I don't /ignore ;-)
[gentoo-dev] Re: List of ebuild functions that die/do not die
Nirbheek Chauhan wrote: On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein car...@gentoo.org wrote: Nirbheek Chauhan wrote: [snip] commands that die: everything that is implemented as a function (ebuild.sh, eclasses, etc) [snip] Technically the rule is that eclasses shouldn't die. At least that's the latest version of the rules that I remember. eclasses shouldn't die or functions inside eclasses shouldn't die? I meant the latter: s/(ebuild.sh/(inside ebuild.sh/ The only technical reason not to allow an --or-die (or the equivalent) switch for everything is the issues with subshell die, for which I sent some script to test but didn't hear back about, but more cogently that old GNU heads think xargs is necessary as GNU find didn't implement -exec correctly (according to POSIX) until a couple of years ago. In BASH, one would use the equivalent loop (which will cope with any filename): while read -rd '' f; do foo --or-die $f; done (find .. -print0) I usually show newbs this: while read -rd ''; do arr+=($REPLY); done (find .. -print0) ..since it shows a bit more about read and gives the other usual requirement. This is compatible with the old broken GNU find as well as BSD, but -print0 is not required by POSIX. I'm sure I've used that in a function somewhere amongst one of the patches I filed with someone or the other. TBH a professional BASH scripter would sneer (I can think of several) at needing to wrap it in a function: it's like not knowing how to read a file line-by-line in POSIX sh. Put it this way: if you actually need the filenames, or some other information elsewhere in the script[1], chances are that the loop has more meat to it. I suppose you could pass directories and params for a find command/API function, eg: findE --or-die foo dirA/b dirC/d ! \( -type -l -o -name '*~' \) ..or the like, showing --or-die first for consistency but it could of course come anywhere. [1] /msg greybot faq disappear
[gentoo-dev] Re: bash version in ebuilds/eclasses...non-compliance and what to do?
Jeremy Olexa wrote: This causes me pain on my hosts that don't have =bash-3.1[0] for /bin/bash. Because I can't install portage with an old bash until I get a new python installed which uses python.eclass which isn't supported with my /bin/bash (quite circular indeed) Technically there are workarounds for me...but it is still annoying. So...what do we do? A) Specifically allow =bash-3.1 features in ebuilds/eclasses. or B) revert the commit because the PMS says[1] that we comply with bash-3.0 Please discuss, thanks. I'd vote for updating the spec; it's going to be a pita trying to maintain the tree without +=. From our discussion, you said it was fine for prefix to specify a minimum version of bash for bootstrap, but clearly that can't be 3.1 when the draft PMS says 3.0. I note that bash-3.2_p17-r1 is stable on all the architectures that 3.0-r12 lists (it just adds the two -fbsd archs as unstable.) portage-2.1.4.5 requires at least that version (only unstable on mips as against 2.1.1-r2) It might be worth skipping to 3.2, since that would simplify regex handling. Not sure how that should be framed, or when it's okay to do it; clearly a spec has to be updatable, whether it's by a specified policy, or explicitly.
[gentoo-dev] Re: app-admin/eselect needs YOUR help
Donnie Berkholz wrote: Ciaran McCreesh wrote: Donnie Berkholz wrote: I hadn't heard of it before, thanks for the ref. What was the reason for forking the codebase? It gets pretty annoying to copy across useful changes, especially while eselect is stuck in svn. Ease of getting things done. Going through Gentoo requires finding a Gentoo maintainer, endless bikeshed arguments about how to implement things like the new alternatives framework and then months of waiting for approval. Open and public debate about the right way to do things does take longer, and it's something you certainly participate in quite frequently so I'm surprised to hear you badmouth it when it comes to your own ideas. You should have posted this to -project imo, as it's not about any technical points, but rather about non-technical aspects of development.
[gentoo-dev] Re: Re: debug/release builds extensions/clarification proposal
Maciej Mrozowski wrote: On Monday 01 of December 2008 09:36:12 Diego 'Flameeyes' Pettenò wrote: - USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not appropriate What are you saying here? I'm afraid you're mistaken here. The point is to look at this from users' (well, a bit) point of view - Dunno who else would be using the software, so agreed ;) USE=debug variable is ambiguous in it's meaning. While it enables only codepaths (asserts, #ifdefs and similar) it suggests (by name and for some packages not only suggests) enabling debug symbols. It'd be much saner if it did exactly what you're suggesting imo. And policy is to enforce CFLAGS from make.conf and wipe out every package- defined flags as far as I know. For the most part, USE=debug means enable debug code paths, which for lots of projects simply means enable assertions; there are packages that take this as enable debug symbols too but I don't think that's very valid since users might want debug code paths but not symbols and vice-versa (I indeed have debug symbols bug no debug codepaths enabled). Let's address the common use case first is often used as an excuse for let's not deal with any other use case. Why should your use-case override the vast majority of users? It's not like you don't know how to configure things exactly how you want or anything, so what's the issue? If you're saying you want your extra feature (in the software engineering sense) I agree it's perfectly valid; it's just lower priority, and I'm sure you can do the work on that bit in a flash. (So far all i've heard is adding -DDEBUG which is hardly ground-shaking.) That's correct, the problem is - Gentoo does not provide officially supported mechanism of enabling both or just debug symbols per package basis - it doesn't even provide any supported/documented mechanism for per package CFLAGS, FEATURES and similar. Indeed; ain't it pathetic? 3 years arguing about PMS and still can't manage the basics. (Answers to this point on -project please.) If /etc/portage/env hack/feature could be made official It's the only sane solution; even if you advocate changing the name for political reasons. I'd recommend looking at[1] and the previously-linked post for a nice way to do both libs and apps (in the common case.) Yet, I still cannot think of this proposal other way like of dirty workaround for the problem, that doesn't really exist (well, at least for developers, who have meta-distribution and ultimate freedom for user in mind). For the users the problem is real, of course it's usually a consequence of either not being aware of those mechanisms or as a result of ambiguous semantics of USE=debug. Ahh but devs _are_ users (except when they're not.) And what about pushing some bash-domain FEATURES to USE flags? Like nostrip, splitdebug? Good idea. I guess being able to set it per package is important. You only get real choice if you have a commit bit ime. Then you're allowed to ask all the inane luser questions you like too. No, I don't get it either (it's hard to distinguish the respect from the flames sometimes, is about as much mitigation as I can dredge up;) but it's off-topic, as was a large part of this thread ; Use gentoo-project for the non-technical aspects (yes, _you_ have to separate your posts first: you don't have that bit, remember?) [1] http://forums.gentoo.org/viewtopic-p-5192821.html#5192821
[gentoo-dev] Re: Re: Please review: function epunt_la_files for eutils.eclass
Peter Alfredsen wrote: I've given this some thought and I think I've been convinced that dberkholz' position is probably the most tenable. If this is to be done, we should do it in a documented Gentooish way. The problem with going down the FEATURES road are two-fold: 1) What should the behavior of the FEATURES flag be? I think it should act like an INSTALL_MASK=*.la and EXTRA_ECONF=--disable-static There should also be a function, let's call it exemptthis.la that would exempt a .la file from being punted, so the RESTRICT could be made on a per-la file basis. If it's a FEATURE defaulting to off, which makes sense from the opt-in perspective, surely a simple Property would do the job for most cases? 2) Who implements in portage? [...I know nothing of portage internals...] Properties are bedded in, all you need is a bit of BASH, to be run for those packages you maintain; and to add the functionality you mentioned above, etc. 3) Grunt work? This should be rather easy. Just assign the bugs to me and I shall add RESTRICTs as-needed. Might be wise to prove it on a smaller subset first, for those packages where you know it's not going to cause an issue, and if it did it wouldn't cause a machine to be unbootable. (Personally I'd understand a user being peeved if they couldn't get their desktop up, but it's not that big a deal provided there's an easy command to run to fix it, and there's notice given; this is Gentoo, after all.) Anyway, we really need to start punting .la files one way or the other. For desktop users of our distro, they do a lot more harm than good. For embedded, perhaps static linking serves some purpose, but really, if you can't afford dynamic linking, what are you going to run on your board? Libtool is sweet from a software developer's pov, especially in its heyday. OFC it might cause distros a bit of aggro, but hey you get to decide what to patch and how. I'm in favour so long as it is only ever an opt-in, or not enabled in anything but developer or desktop/Linux profiles (the latter after at least a year or two of testing and bug resolution.)
[gentoo-dev] Re: Reinstating eclasses
Duncan wrote: Joe Peterson wrote: In general, it makes sense to me to have an unversioned one if there is no version dependency - i.e. if xfce.eclass would likely work for future ones (like xfce5). I'm not sure why, other than to emphasize that a new version is out, upstream packages (like gnome, kde, etc.) include the version in the name. I actually just think of kde as kde, myself, even if it happens to be version 4. ;) FWIW, KDE changes major versions seldom enough and with enough differences between versions, that it's a good time to break package handling and get rid of the cruft at the Gentoo level as well. That's a valid reason, although eclass versioning (which someone, can't mem who, not a portage dev, told me was round the corner) would solve it more cleanly across the tree and allow the simplest name. The attraction of staying with one name is that the eclass can transition ebuilds and then lose the cruft once the packages are out of tree. Given that eclasses can test and change according to EAPI, what we have now would seem sufficient unless there is a major build system change, like KDE4 switching to cmake. Presuming something similar for xfce, if xfce4 is taken but xfce isn't, that would work, or perhaps xfce4ng.eclass... *ng is always good for a round... and if it comes to it beyond that, g3, g4, etc. Of course, that's sort of like Gentoo's -rX numbers for ebuilds, but the -rX concept doesn't so well lend itself to the eclass concept as it implies a rather faster turnover than we'd /hope/ to be the case, but -ng/-gX, that works. =:^) I like that naming schema but think it might be overkill here. Might be a more flexible way to do epochs, but I'm not sure we'd need more than one comparable value, and I think sticking to one int is sufficient.
[gentoo-dev] Re: Flags to punt (including: kerberos USE flag)
David Leverton wrote: On Monday 03 November 2008 04:29:34 Nirbheek Chauhan wrote: Why not use EAPI=1 for those ebuilds and turn the flag on by default? Well, as I said, it seems more sensible to me to set the default once, instead of once for each ebuild. I don't particularly care, though, just making sure people know why it was there in the first place, and if they still want to change it, so be it. I concur, it is more sensible. Dunno how you get round the maintenance issue, apart from scripts around the time someone leaves or sth. Maybe if they're all/substantively from an eclass, it definitely must not be in a profile would be a good policy.
[gentoo-dev] Re: [PMS] Add RESTRICT=distcc capability
Ciaran McCreesh wrote: On Sun, 2 Nov 2008 12:11:10 -0700 Gordon Malm [EMAIL PROTECTED] wrote: Have you conclusively established that they do build fine in parallel? If so, how? Yes it builds in parallel. By compiling it in parallel. If you think compiling it in parallel confirms that it builds in parallel, you're reaffirming my growing suspicion that you're entirely wrong about distcc being responsible for anything other than hardened brokenness... Well my understanding of parallel make is that it would show some issues but not all. I'd hope you were trying to say: Build it via distcc with N virtual hosts or sth along those lines. RESTRICT=distcc on kernel modules is unnecessary for the large proportion of users who don't use hardened. RESTRICTs can't be set dependent upon whether or not something like hardenened is enabled; other mechanisms are available that can be. So why aren't you considering those other mechanisms? I agree with the first sentence, never said otherwise. Who says I am not considering them? In fact, I have stated that I am. More why hasn't he proposed them already. They are just more hackish than adding the ability to RESTRICT distcc, hence my reason for soliciting such a feature. I'm surprised that you'd suggest this after debasing a RESTRICT option on the same grounds. And that brings us to the other thing you don't understand: RESTRICT is a global, system independent, invariant metadata key. Things in RESTRICT are in RESTRICT because they have to be known in situations where those constraints are in effect. those constraint are in effect isn't a good way of explaining that imo. Things that do not have to be known at the metadata level shouldn't be in metadata. Yeah, stuff that always applies, no matter what. Sorry to everyone who e-mailed me who thought RESTRICT=distcc would be somewhat useful. Well a user could always turn off FEATURES externally, which isn't hard to automate[2]; developers are notoriously bad at defining use-cases. Those people are mistaken. Uh, that's your answer to technical objections to a proposal? You aren't prepared to defend your proposal on its merits? I think those two bits go nicely together. It's not supposed to be a fight, btw. Why are you assuming this point is *at all* related to my proposal? It's not. It's about Gentoo. But I stand corrected, a bunch of people rushed to tell me you don't actually determine anything. ;) So you don't care about whether your solution is right? *sigh* You are proposing to add a metadata invariant option for a condition that isn't metadata invariant and that, by being made metadata invariant, means it's being disabled for everyone rather than by the small number of users who might need it. In addition, you can't demonstrate any cases where this option is genuinely useful, other than as a workaround for a hardened bug that you haven't contacted upstream about, and when used to work around said hardened bug the scope of the change isn't limited to hardened. I agree this case isn't the best one, nor am I in favour of this RESTRICT. I'm totally neutral on it as a solution. I can envisage wanting to restrict compilation to the local machine, but I'm not bothered about how it gets done. My instinct would be to err toward giving the control to the ebuild maintainer, with a clear QA policy, perhaps around making it something that had to be reviewed on every bump (QA script to watch ebuild as long it has the RESTRICT, unless it's proprietary.) Much as we might want perfect builds, they don't always happen, nor do we always have time to fix upstream bugs, however minor they turn out to be. You still haven't explained why you don't do something like: broken_hardened_compiler export DISTCC_HOSTS=localhost Still it would have been easier on the reader if you'd just mentioned this first. [1] http://hardened.gentooexperimental.org/trac/secure/ [2] http://forums.gentoo.org/viewtopic-t-546828.html
[gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
Peter Alfredsen wrote:
debug-print-function $FUNCNAME $*
You should be using $@ not unquoted $*.
Seems like the FUNCNAME bit should just be rolled into the function
with ${FUNCNAME[1]} which could be done tree-wide quite easily.
[gentoo-dev] [project] Re: [RFC] some global useflags
Ryan Hill wrote: Steve Long wrote: Ciaran McCreesh wrote: Steve Long wrote: Have a look at, for example, [1], where Mike already gave you an answer one of the previous times we discussed it. I'm aware of the prior discussion. Re-read it, and tell me what it breaks, if you can. Well, which part of the previous times it's been explained to you didn't you understand? No one has ever given me a technical reason. I thought you might have light to shed; clearly not. Please don't reply to my posts if you don't have any actual information to add; I realise you like long fruitless mail 'discussions', and apparently have lots of time for them, but I don't, and I don't enjoy reading them either. This kind of one-liner with zero content, and no intent but to insult, should simply be binned without sending imo. Okay, Steve, stop. I don't think you realize it, but you are trolling this list. That wasn't my intention; I added that comment simply to stop the flow of one-line emails. Every second post is you and Ciaran bitching at each other I do wish one of you devs would pick him up on his behaviour _on the list_ one of these days.. instead it's _always_ me who gets the flak. Or do you think his post was anything other than a one-liner with zero content, and no intent but to insult? or you complaining about every single thing we do that you don't personally like. Not complaining, simply pointing out better ways to do things; a technical discussion iow. The reason that has been more difficult a discussion than it should be is because of the unpleasant comments from McCreesh, Ferdy and Leverton. We appreciate your input, but please respect our right to do things the way we think is best for us, even if they aren't aligned to your personal preferences. I was never under the impression that Gentoo devs would do anything other than whatever they wanted. Can you tell me what a 'server' USE flag _breaks_?
[gentoo-dev] Re: Re: Re: [RFC] some global useflags
Ciaran McCreesh wrote: On Thu, 16 Oct 2008 22:06:40 +0100 Steve Long [EMAIL PROTECTED] wrote: Have a look at, for example, [1], where Mike already gave you an answer one of the previous times we discussed it. I'm aware of the prior discussion. Re-read it, and tell me what it breaks, if you can. Well, which part of the previous times it's been explained to you didn't you understand? No one has ever given me a technical reason. I thought you might have light to shed; clearly not. Please don't reply to my posts if you don't have any actual information to add; I realise you like long fruitless mail 'discussions', and apparently have lots of time for them, but I don't, and I don't enjoy reading them either. This kind of one-liner with zero content, and no intent but to insult, should simply be binned without sending imo.
[gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Arun Raghavan wrote: I've not really got an opinion on the topic, per se, but fwiw, this is really not a meaningful statistic. *If* parsing strings in the ebuild is not a trivial part of the overall ebuild parsing process, then yes, this is a significant gain and should be treated as such. I find it unlikely that this would be the case. Sure, it's nothing that major, it's just one example of a free performance increase. (Although I would point out that parsing strings is basically what shells do.) Sure, that's nothing in the context of the actual install, but there were a few comments in the huge GLEP-55 thread about performance during cache generation. I'm not sure how one can go about measuring the impact of this on ebuild parsing as a whole. Maybe make take a few typical ebuilds, change quoting style, and run it through ebuild.sh in a loop. All the inherited eclasses would need to change too, though, I guess. Yeah, though I won't be doing it, I've kinda lost my enthusiasm; if anyone's learnt something they didn't know before, that's good enough.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Peter Volkov wrote: Steve, your example only tests how much time bash takes to parse string. It's obvious that in quoted strings some expansions could be avoided and thus bash works faster. Yeah that's all I wanted to get across. But although ebuilds use bash syntax they are interpreted not only by bash - the time to parse stings is negligible to other activities. I have not calculated but made a rough estimation taking into account the number of ebuilds in the tree. So I think we have of order of 10^6 string. This means that during merge of all packages we'll win 10 seconds. I don't think it's worth to consider this gain. Agreed; in the context of a build it's not at all significant. It might be in the context of metadata generation. So in portage tree this is the matter of style. That's said, since personally I don't have any preference on this style and until there will be arguments not to use this style I'll start to use full quotation of the strings. Thanks for taking it on board :-) And yes, in pure bash programs possibly this'll make sense. Yeah; that's effectively what ebuild.sh, combined with all the files it sources, is. (There's quite a bit of code there.) Regards, Steve.
[gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Ciaran McCreesh wrote: On Wed, 15 Oct 2008 20:28:43 +0100 Steve Long [EMAIL PROTECTED] wrote: Fernando J. Pereda wrote: A big gain in the context of ebuilds and source packages. Well done. Yes, almost as important as not sourcing any ebuilds, so let's all stick an EAPI extension on the end of the filename. If you really think that EAPI as an extension has anything to do with performance You mentioned performance a few times in that lovely thread when it got shot down, I believe in the context of metadata generation: Performance hit (when discussing an alternative) [1] The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. [2] It's several more directory reads. This is a measurable performance hit [3] Are you now saying performance doesn't matter? , you are even more sadly mistaken than usual My how the insults fly.. must be a new academic year. , and I suggest you lay off the GLEP 55 bashing until you've bothered to read it. Yeah cos obviously I never read it when it was last discussed. Way to go with unfounded, clearly absurd, assertions. [1] http://article.gmane.org/gmane.linux.gentoo.devel/53512 [2] http://article.gmane.org/gmane.linux.gentoo.devel/53751 [3] http://article.gmane.org/gmane.linux.gentoo.devel/53668
[gentoo-dev] Re: Re: [RFC] some global useflags
Ciaran McCreesh wrote: Steve Long wrote: Ciaran McCreesh wrote: Markus Meier wrote: server16 Already been discussed, can't be done. What does it break? Have a look at, for example, [1], where Mike already gave you an answer one of the previous times we discussed it. I'm aware of the prior discussion. Re-read it, and tell me what it breaks, if you can.
[gentoo-dev] Re: Re: [RFC] New keywords for non-Gentoo Linux platforms
Michael Haubenwallner wrote:
Fabian Groffen wrote:
Ciaran McCreesh wrote:
Steve Long wrote:
Unless someone can say what using PROPERTIES=prefix would break, I'd
go with that. It's a /classic/ usage of that variable, as it's simply
a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
support it. It'd be great to see the prefix branch finally merged so
we all get to play with it.
It would break. Prefix ebuilds won't work unless ED is set, and a non
PROPERTIES aware or non-prefix-property aware package manager won't set
ED. Unless prefix is reimplemented to require no package manager
changes for the install to / case, PROPERTIES is out.
Nonsense; we just need some bash changes to integrate it iff we want to
allow prefix ebuilds into the main tree; we're a while away from actually
being at the stage where that would be feasible, even if it were desired.
By the time we do get there, we should be able to fulfil your last
condition, given a sane bash implementation for the mangler in question.
TBH I'm not really worried about alternative manglers atm; they can catch up
w/e afaic. IIRC PROPERTIES are part of EAPI-2, so one would hope they've
already done that by now.
Just to comment on this possibility; I see an option, given the
definition of ED and EROOT to do Prefix without them, by e.g. using
${D}${EPREFIX} instead of ${ED} as shorthand. When ${EPREFIX} would be
unset, this would result in simple ${D}, which is backwards
compatible. This is not all what is necessary, but a big deal of it.
Question here, however, is whether this is worth it. Personally, I
prefer the shorthands, as they give a lot of readability.
Yeah the shorthands are nice, agreed. Ideally we wouldn't need to change
anything in the ebuild though. (I appreciate we're a while away from there,
but if we can at least get the ones which go via emake and econf, that's a
start. We can worry about {scons,distutils,..} later; pro-audio have a nice
exteutils.eclass we can 'borrow' for a start ;)
From the prefix docs, the only place D should be retained over ED is in a
DESTDIR=$D (or ${D}) when configure --prefix=.. has been run. Is that
correct?
Could it also work to initialize them in profile.bashrc if they are
unset?
Something like
: ${EPREFIX=}
: ${ED=${D}}
: ${EROOT=${ROOT}}
That would work yeah, though I think it would be better if we just
integrated that into ebuild.sh. We can check PROPERTIES to see if prefix is
in there, and then enable additional logic, and eg use a different PATH for
external helpers (most of which we can do internally in any case.) I
realise the latter is happening already, but if we're integrating, it
should be happening in the mainline code when applicable, imo. (Not saying
that is the applicable case, just that we can change w/e you see fit.)
[gentoo-dev] Re: Re: bzr.eclass into Portage
Bo Ørsted Andresen wrote:
On Monday 13 October 2008 04:43:48 Steve Long wrote:
EBZR_OPTIONS=${EBZR_OPTIONS:-} (and similar variants)
doesn't do anything (beyond waste lex and yacc time.)
It gets listed in the generated man page.
From what I remember of the awk that generates those manpages, this:
# @ECLASS-VARIABLE: EBZR_OPTIONS
# @DESCRIPTION:
# The options passed to the fetch and update commands.
..does that.
The same consideration applies to all those constant values 'and
indeed' ${foo} as opposed to $foo, though first time I raised that I got
sworn at, so not expecting miracles here.
Are you for real?
Perhaps you missed the discussion about EAPI in filenames?
[gentoo-dev] Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs
Alec Warner wrote: Petteri Räty wrote: There's no need to commit straight to stable. Just make two different new revisions for each EAPI. Then the arch teams can test it like usual. Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are there multiple versions of the same package' questions and complexities. Hmm AFAICT there isn't any need to do put it in the filename, as the package manager will simply ignore an EAPI (which comes from the rsync'ed cache for the Gentoo tree) it doesn't know. Additionally all the manglers deal with EAPI 0-2 fine afaik. If it's solely about the different rev ids, I think it's a bit of a red herring; anyone confused could simply be told this is a security fix if they cared to ask (or look in the Changelog) and these aren't exactly going to be all over the tree. Could be masked for arch-testing [security fix] and then the relevant fixed older version put into the tree, as now. Personally I'd rather remove the restriction and allow ebuilds to work with more than one EAPI, as explicitly declared, instead of having to write two revisions. One could then also inherit from a security eclass to make it clear to anyone reading the ebuild what was happening (which would also work for two different revs with variant EAPIs ofc.) Whatever, I don't think this use-case is anywhere near enough to justify the massive intrusion that GLEP55 is. The versioning thing brought up before is best done via debian-style epochs, if anyone really wants to fix that.
[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Jan Kundrát wrote:
Steve Long wrote:
insinto /usr/share/doc/${P}/examples
Is there any chance we can start using correctly quoted filenames across
the board?
Since when is ${P} allowed to have spaces?
I believe I answered this in my prior post.
Besides being faster (quote the whole thing)
Have you done a benchmark certifying that /usr/share/doc/${P}/examples
is faster than /usr/share/doc/${P}/examples?
Here you go (this is on an old machine, so you'll get much quicker times if
you try this at home):
[EMAIL PROTECTED] ~]$ echo $(run)
#!/bin/bash
P='some-crap/god-i-hate-asshats'
for ((i=0;i10;i++)); do echo /usr/share/doc/${P}/examples /dev/null;
done
[EMAIL PROTECTED] ~]$ echo $(run2)
#!/bin/bash
P='some-crap/god-i-hate-asshats'
for ((i=0;i10;i++)); do echo /usr/share/doc/$P/examples /dev/null;
done
[EMAIL PROTECTED] ~]$ for ((l=0;l5;l++)); do time -p ./run; done
real 11.25
user 9.96
sys 1.13
real 11.12
user 9.82
sys 1.16
real 10.99
user 9.70
sys 1.15
real 11.25
user 10.02
sys 1.07
real 11.36
user 10.06
sys 1.16
[EMAIL PROTECTED] ~]$ for ((l=0;l5;l++)); do time -p ./run2; done
real 9.24
user 8.00
sys 1.11
real 9.22
user 8.02
sys 1.08
real 9.08
user 7.90
sys 1.06
real 9.23
user 7.96
sys 1.15
real 9.18
user 7.98
sys 1.09
more useful error messages in the case of a dev/user slip-up
Could you elaborate?
File not found foo/bar bar/ as opposed to two separate lines; for elib
functions, one would expect there to be an error handler which would be
wrapping that, per-parameter.
They also highlight better in a capable editor.[1]
Please elaborate.
I did.
[gentoo-dev] Re: System packages in (R)DEPEND?
Peter Volkov wrote: Jeremy Olexa ?: Thomas Sachau wrote: Should we depend on all system packages? Should we depend on some packages, because they could be removed? If yes, which ones? Or should we leave the system packages out completly? https://bugs.gentoo.org/show_bug.cgi?id=221311 Please provide reasons/justifications for the proposal of removing Our documentation, QA team insist that we should not depend on system packages and there are good reasons to do that. But still above bug clearly states different. Also if we consider perl and some other packages, they also could became target to be removed... But I'm not going to repeat discussion we already had recently: http://thread.gmane.org/gmane.linux.gentoo.devel/54035 So yes, there is ambiguity and the question is valid. But since we had discussion recently I don't see what else we can discuss now. Well according to [1] it should all be done in the profiles, and [2] seems like a good way to accomplish a more effective split. Is there anything which means portage can't simply move ahead with that? [1] http://article.gmane.org/gmane.linux.gentoo.devel/54146 [2] http://article.gmane.org/gmane.linux.gentoo.portage.devel/2575
[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Fernando J. Pereda wrote: On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote: Here you go (this is on an old machine, so you'll get much quicker times if you try this at home): A big gain in the context of ebuilds and source packages. Well done. Yes, almost as important as not sourcing any ebuilds, so let's all stick an EAPI extension on the end of the filename.
[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
David Leverton wrote:
On Wednesday 15 October 2008 10:33:22 Steve Long wrote:
Here you go (this is on an old machine, so you'll get much quicker times
if you try this at home):
[EMAIL PROTECTED] ~]$ echo $(run)
#!/bin/bash
P='some-crap/god-i-hate-asshats'
I do hope that that isn't directed at anyone in particular.
No, but thanks for drawing attention to it.
for ((i=0;i10;i++)); do echo /usr/share/doc/${P}/examples
/dev/null;
real 11.25
real 9.24
So that's what, on the order of 20 microseconds faster for each iteration?
Or ~18%. (You shouldn't use the first iteration in general, btw.)
This is a purely stylistic issue, same as the braces with variable
expansions.
See my other posts.
You're free to write your own code however you like, but
harassing other people to do things your favourite way with no practical
benefit is just going to annoy everyone.
I'm sorry you feel harrassed by my talking about the basics of
shell-scripting, it wasn't intended like that. Though, given your tone, I
don't think you are feeling harrassed; perhaps you're just feeling
defensive about your trap boo-boo? Whatever, leaving aside the amateur
dramatics, it was more to show how to do the benchmarking than anything
else; I'd have simply said yes but that reminded me too much of behaviour
I have criticised in the past.
For the record, I'm sorry if my choice of package name caused any offence to
anyone else. It was a quick thing I knocked off, cp'ed and pasted; at most
I thought it would be taken as a joke when I wrote it, then I didn't check
it through in the correct frame of mind (I have flu and was tired, so just
wanted to send the thing and didn't check the script itself) when I sent
it, and for that I apologise to everyone reading.
[gentoo-dev] Re: [RFC] some global useflags
Ciaran McCreesh wrote: On Wed, 15 Oct 2008 18:36:32 +0200 Markus Meier [EMAIL PROTECTED] wrote: server16 Already been discussed, can't be done. What does it break?
[gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Peter Volkov wrote:
Robert Buchholz ?:
Thilo Bangert wrote:
HOMEPAGE=http://this-package-has-no-homepage.gentoo.org/;
Why not use our package site for this, i.e.
HOMEPAGE=http://packages.gentoo.org/package/${CAT}/${PN};
This is not homepage. HOMEPAGE should point to package dependent
information or in other words to upstream.
Er it is package-specific, and this is for where there is no upstream.
Same stands to existent or nonexistent link on gentoo.org or any other
domain. This is even worth as this solution also makes users to open
another page which just tell them that homepage does not exist...
No, the packages site links to a forum search (I'd personally make that
a 'site:forums.gentoo.org' google search across the board, since it's so
much handier, and get some adsense bucks while you're there;) and a
bugzilla search, as well as giving information about all the available
versions in the tree. You should check it out ;p
So I think if HOMEPAGE does not exist then it's better either put some
constant there or better make it empty. If we wish, for packages with
empty HOMEPAGE we can teach tools like emerge -s or eix to show Home
page unknown or Homepage does not exist. Simple and clear, what else
do we need? :)
An easy way for Gentoo users to contact other people using the software;
given that it's available on Gentoo, and officially dead as far as Gentoo
is aware, having the cli interface display that url (however formulated) is
a plus in support terms, and maybe one day getting the package resurrected.
A gui wrapper like himerge would display the link as clickable, as would a
suitably configured xterm.
So while I agree the empty value in the ebuild is the way to go, I'd
personally like it a lot if Portage at least displayed a useful url (and
the website was ok with it.) If you're going that far for the official
mangler and the site, it seems like something to mandate/specify (I
really /don't/ want to file that bug;)
Is there at least consensus that the above formulation wrt user-display, and
zero-length, would be useful?
(Leaving aside concerns over backward-compatibility/EAPI.)
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Thomas Sachau wrote:
what about this:
insinto /usr/share/doc/${P}/examples
Is there any chance we can start using correctly quoted filenames across the
board?
[EMAIL PROTECTED] NB: I'm raising this as a talking-point, not pushing it as an
agenda,
so please don't reply if discussion doesn't interest you.]
Besides being faster (quote the whole thing) they leave the option in future
of having package names etc with spaces, or at this point, more useful
error messages in the case of a dev/user slip-up. They also highlight
better in a capable editor.[1]
iow: insinto /usr/share/doc/$P/examples
[1] Try kate, if gvim and xemacs don't do it for you: that quoting error of
yours in the other thread would be a very good example-- it simply wouldn't
happen on kate unless you had a very strange (ie functionally useless;)
colour setup.
[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
Jeremy Olexa wrote: Fabian Groffen wrote: snip Most notably, in Prefix all keywords are full GLEP53 style, which results in e.g. amd64-linux. We did this on purpose, because in Prefix we don't necessarily are on Gentoo Linux. We also chose to expand fbsd, nbsd and obsd to their long variants, mainly because the short variants might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD, polyBSD or DragonflyBSD, DesktopBSD. (At some point we were a bit over-enthausiastic.) I would like to hear some opinions on the keywords in general, as well as the particular problem of having Gentoo Linux, and a Linux supported by Gentoo Prefix. Would it not be simpler just to say the keyword can be from 1 to 4 hypen-separated parts, 1 as-is (in both GLEPS) 2 as GLEP 53, 3 with libc change, and 4 with non-default userland as per GLEP22 (perhaps change the order to be more intuitive, if you think it would be better)? Right now there is just the difference of -linux appended, however this is not the clearest distinction between the two. Perhaps using KEYWORDS for Prefix keywords is not the best thing to do, and should we use something like PREFIX_KEYWORDS? Ignoring the bit about how to name the keywords.. ;) I am undecided about Prefix keywords in the normal KEYWORDS variable. In particular, we are overloading the -linux keyword to mean that it will run on any linux that Gentoo Prefix supports. This includes, Gentoo, RHEL, SLES, FreeMint, $OTHER. Is there any problem with overloading the keywords like that? If not, then it shouldn't be a problem to keep prefix keywords in the KEYWORDS field. OTOH, I don't think we should add another variable to ebuilds. Thoughts? Wrt to the variable thing, I agree the specification of prefix is orthogonal to the spec of an EAPI. Orthogonality [at least in sw terms] doesn't just mean nothing to do with it whatsoever, or it wouldn't apply to the software in question. Unless someone can say what using PROPERTIES=prefix would break, I'd go with that. It's a /classic/ usage of that variable, as it's simply a boolean; PROPERTIES is well-defined and I'm hoping all the manglers support it. It'd be great to see the prefix branch finally merged so we all get to play with it.
[gentoo-dev] [project] Re: Re: EAPI-2 and src_configure in eclasses
Ciaran McCreesh wrote: On Tue, 07 Oct 2008 17:07:21 +0100 Steve Long [EMAIL PROTECTED] wrote: It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way. The whole point of PMS is that it provides a way to avoid relying upon implementation specific things. There are currently no packages that rely upon calling phase functions in the wrong place It wasn't about calling it in the wrong place, it was about how you test for whether the ebuild+eclasses provide a function, or use a phase. and there are good reasons a package manager might want to avoid implementing things in a way such that doing so is legal, so we don't allow it. Sure let's keep constraining what the bash side of things can do, as that's nothing to do with the package manager implementation. Also, I don't think it has to be done at that point. I think it's convenient to do it at that point, and when combined with several other reasons doing it that way is the best option. Yes, a mystery wrapped in an enigma wrapped in pure bullsh^W obfuscation is always such fun. Strange how you repeatedly seem to pop up in favour of doing whatever you think will cause most inconvenience to Paludis, though... Strange how you think you can read my mind.. I actually think that not providing functions an ebuild might call in a phase, during the actual install, is not such a good way for the mangler to ascertain ahead of time whether or not that phase will be needed, *irrespective* of how any extant implementation does it. But as you always remind me, I don't know enough to comment-- because you say so. I actually hesitated to get into that discussion with you. I did so as I wanted to query the design decision. You know, a technical _discussion_.. Thanks for reminding me again how incapable of that you are, unless you think there is some political capital to be gained.
[gentoo-dev] Re: Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Brian Harring wrote:
Steve Long wrote:
Robert Buchholz wrote:
Ciaran McCreesh [EMAIL PROTECTED] said:
Robin H. Johnson [EMAIL PROTECTED] wrote:
Either we need special cases to declare that it no longer has a
homepage, or we need to allow the empty HOMEPAGE.
HOMEPAGE=( )
HOMEPAGE=http://this-package-has-no-homepage.gentoo.org/;
Why not use our package site for this, i.e.
HOMEPAGE=http://packages.gentoo.org/package/${CAT}/${PN};
++ This makes the most sense; it's simple and it enables users to
interact with the appropriate channels to get support, or file bugs and
patches.
If a notice is needed, the website can be amended to state explicitly
that upstream is dead (if the homepage points to self.)
Use a constant of some sort rather then having the ebuild hardcode the
fallback- this shifts the fallback upto the PM (code rather then data
it operates on) allowing far more flexibility.
Sure, so long as the end-user always sees:
$GENTOO_PKG_URL/package/$CATEGORY/$PN (or whatever the current schema is)
in the cli, it doesn't matter. The argument would be for someone reading an
ebuild, but I don't think that really matters, as by that time they'd have
got used to seeing the packages url, and it's a one-line comment in the
example file/docs to explain it.
If UNKNOWN or some other non-empty constant is chosen, it's a simple bug to
spot and fix for any externals that don't display it correctly. Have to say
I'd prefer simply allowing empty string in the tree, though. No i18n issue
and it's very well-understood/defined, and seems cleaner (less cruft too.)
Perhaps repoman could allow an empty homepage, but not an unset one?
An example for why this is a better approach would be if I get really
really bored some afternoon (or exceedingly drunk) and try to match
the package back to a freshmeat url when the homepage is
unknown/unset; using a constant, I can focus on that fun task.
That sounds more like a script-task to me. (plus it doesn't matter how
wasted you are;)
Use a constant of some sort please, it's way saner from a data format
standpoint.
Agreed.
[gentoo-dev] Re: developer profile
Duncan wrote: Thomas Sachau [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 05 Oct 2008 14:24:55 +0200: I just had a user in bugzilla who thought, the developer profile would be for software developers, not just for gentoo developers. Probably he is not the only one. What about either adding some big warning on portage output or renaming this profile to e.g. gentoodeveloper? There's a thread in the archive discussing this. The conclusion then seemed to be that the traditional profile.bashrc test for I_KNOW_WHAT_I_AM_DOING=yes, with a suitable warning if it wasn't set, should be enough. The problem with that is that the profile itself sets that var in profiles/targets/developer/make.defaults, so anyone using the profile has it set automatically, rather defeating the purpose of the test in the first place. The solution would be to remove that bit from profiles/targets/developer (and other places it may be set in the profiles, forcing those using the developer profiles to actually set it themselves. If they don't, they get the warning. That seems like a clean (and simple) solution. If they see the warning and set it anyway, well, one would hope they /do/ know what they are doing, and if they don't, as the saying goes If it breaks, you (they) get to keep the pieces! I'd suggest a somewhat less generic var as well. Perhaps I_AM_A_GENTOO_TESTER_AND_I_KNOW_WHAT_I_AM_DOING, or maybe I_KNOW_THIS_MAY_BREAK_BUT_I_AM_TESTING_AND_KNOW_WHAT_I_AM_DOING. Wooh, calm down there ;) Longer synonyms with no additional semantic data don't help anyone ime; it's already long enough (and, speaking as an end-user, typing it in does make you stop and think about what you're doing, after you stop laughing, so it does serve its purpose.) Or make the profile.bashrc test for both the var and a more specific value, perhaps like this: I_KNOW_WHAT_I_AM_DOING=and I know it can break but I am testing Hehe. I think just doing what you mentioned above, ie not setting it in the defaults, but allowing the user to do so at installation (or whenever) would solve it. The loud warning notice does put casual users off, and it should be enabled by default for arguably any unsupported profile. Devs will no doubt be quick to set up their own machines as and how they want; expecting a single additional config var in amongst the make.conf template isn't such a big deal, and keeps the support burden down.
[gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Robert Buchholz wrote:
On Sunday 05 October 2008, Thilo Bangert wrote:
Ciaran McCreesh [EMAIL PROTECTED] said:
On Sun, 5 Oct 2008 03:44:20 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:
Either we need special cases to declare that it no longer has a
homepage, or we need to allow the empty HOMEPAGE.
HOMEPAGE=( )
HOMEPAGE=http://this-package-has-no-homepage.gentoo.org/;
Why not use our package site for this, i.e.
HOMEPAGE=http://packages.gentoo.org/package/${CAT}/${PN};
i.e. for this particular use case,
http://packages.gentoo.org/package/app-mobilephone/smssend
The site contains a link to ChangeLog, description, current version,
forums and bugs. I would suggest it is the most usable homepage a user
can expect if no other exists.
++ This makes the most sense; it's simple and it enables users to interact
with the appropriate channels to get support, or file bugs and patches.
If a notice is needed, the website can be amended to state explicitly that
upstream is dead (if the homepage points to self.)
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Alexis Ballier wrote: Indeed; different names could be given to different implementations of the same thing, but that might completely kill the point of abstracting it. Maybe eclasses should die on unknown eapi; the fact is I really hate the current way it's done when switching an ebuild to EAPI-2 which uses an eclass that exports src_compile; most eclasses don't special case eapi-2 yet and we end up running econf twice at best. I fear that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll support src_configure too) An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi would help too. Ciaran McCreesh [EMAIL PROTECTED] wrote: An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place checking for eclass screwups... yes; that's just a matter of choice though, but for eclasses it's probably not luxury. Well it's simple enough to check (and give a QA warning) for unknown functions; adding a check for a specific string prefix (or to exclude a certain subset) in EXPORT_FUNCTIONS (based on current EAPI) is simple enough too. Is that what you mean? The behaviour to trigger could change eg for debug mode, or a repoman check. I don't quite see how that deals with an eclass calling econf in its exported src_compile? Seems like EAPI versioning for eclasses (with implicit 0 only) is more what you're after for that issue (so the PM could suppress src_configure if src_compile is going to resolve to an EAPI-0 eclass function, although the inheritance stack might prove problematic.) Having to die for an unsupported EAPI seems like the wrong approach; if it's not going to work the PM shouldn't source it. If it can be made to work by filtering certain functions, that's doable. In the worst case, an ebuild switching to EAPI will require eclass maintenance; this is where the separation of elibs (useful code) and eclasses (template ebuilds) would be useful, although that needs versioning too.
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Ciaran McCreesh wrote: On Sun, 5 Oct 2008 17:38:11 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells has my eapi foo support but that sort of bites its tail that way. Hm, what about: [ $(type -t src_configure) == function ] EXPORT_FUNCTIONS src_configure Or is this too fragile or trying to be too clever? It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way.
[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Zac Medico wrote: Rémi Cardona wrote: Zac Medico a écrit : Please consider a PROPERTIES=set value that allows an ebuild to indicate that it should behave like a package set when selected on the command line. This is behavior is somewhat difficult to describe in words but the following example should be sufficient to convey the general idea. As one of the maintainers of the gnome-base/gnome meta, I fail to see the usefulness of such a change. We have yet to ask users to rebuild gnome completely. Do you have any specific use cases (maybe coming from the KDE herd, since you used the kde meta as an example) ? The one thing that bothers me about this is consistency: if, say, xfce (let's change ;) ) decides to use PROPERTIES=set, users will have a different experience with their ebuild than with the other metas we currently ship. Only when they consciously use the set syntax, surely? All in all, I'm not really against such a change, however I really fail to see the win for everyone, end-users included. Over the course of the discussion I've revised the idea so that it essentially represents a way to define a package set, without any changes to existing behavior. What will change is that we will have a new way to define package sets, based on ebuilds. Makes sense to me, though not sure you need the mapping file. I'm perfectly happy about emerge -uDN @kde-meta say, updating all kde-meta packages I might have installed; I take it that after emerge kde-meta to install, and then removing some of the packages, the user could continue to reference the set for upgrade, without portage reinstalling those?
[gentoo-dev] Re: Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Zac Medico wrote: Steve Long wrote: Zac Medico wrote: Rémi Cardona wrote: As one of the maintainers of the gnome-base/gnome meta, I fail to see the usefulness of such a change. We have yet to ask users to rebuild gnome completely. Do you have any specific use cases (maybe coming from the KDE herd, since you used the kde meta as an example) ? Over the course of the discussion I've revised the idea so that it essentially represents a way to define a package set, without any changes to existing behavior. What will change is that we will have a new way to define package sets, based on ebuilds. Makes sense to me, though not sure you need the mapping file. I'm perfectly happy about emerge -uDN @kde-meta say, updating all kde-meta packages I might have installed; I take it that after emerge kde-meta to install, and then removing some of the packages, the user could continue to reference the set for upgrade, without portage reinstalling those? That would be a set subtraction operation, so the user would use a configuration file to configure the set so that certain unwanted atoms are automatically subtracted out. Alternatively, we could implement a syntax extension for optional atoms that are only pulled into the dependency graph if they happen to be installed already. It would be nice to address it; wrt people installing a meta which will define a set, it'd make it easier to maintain (a box) if the set syntax referred to whatever was installed, whereas emerging the package would install all its deps as a standard virtual does (in the default setting.) Integrating seems like a good idea, wrt to the USE settings you discussed in the other thread. There is already a framework in place to model all that, and more, so might as well use it. (I'd vote for allowing as much flexibility as the ebuild author wants to specify.)
[gentoo-dev] OT: Re: Default src_install for EAPI-2 or following EAPI
Ulrich Mueller wrote: As I said; generality in lib functions seems like a useful thing. Other ebuild variables are space separated lists, so why should DOCS be an exception? Because we're doing it right this time, while allowing existing usage. IOW you can quite happily continue to use your space-separated list and it won't matter. If you do ever need a bit more, it'll already be in place. If you never do, how will it hurt you? So far nobody has shown a real-life example of an existing ebuild that could profit from the array syntax. I think Duncan answered the point quite while. In summary that's why for instance no filenames with spaces (leave alone all the other characters you can't deal with atm) can be safely handled by any of your ebuild structure, unless it comes from a glob, and is never manipulated or referenced in and of itself. (Unless you wish to go down the eval route, which believe me is not fun at all.) If you're saying fine we don't need any more control in those packages nothing I can say will be of any use. (NB: packages not programs.) Are you really arguing that reduced functionality is a good thing? There's a quote I read from what is imo a classic computing text[1] (from the 70s, never seen it referenced in any papers or anything): Why do we never have time to do it right, but always plenty of time to do it over. Entia non sunt multiplicanda praeter necessitatem. - Joh. Clauberg (1654) Let him who thinks it is not broken, not interrupt the person fixing it. Chinese proverb (wrongly attributed to some Ancient Roman.)
[gentoo-dev] Re: OT: Re: Default src_install for EAPI-2 or following EAPI
Steve Long wrote: In summary that's why for instance no filenames with spaces (leave alone all the other characters you can't deal with atm) can be safely handled by any of your ebuild structure, unless it comes from a glob, and is never manipulated or referenced in and of itself. (Unless you wish to go down the eval route, which believe me is not fun at all.) Or Roy's shell function thing (ie every array is handled via a function call.) Then we're arguing about how, not why, however (and BASH arrays are much nicer to work with for scripts that aren't just glue.)
[gentoo-dev] [project] Re: Default src_install for EAPI-2 or following EAPI
Duncan wrote: Steve Long [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 22 Sep 2008 01:35:57 +0100: This is an old rhetorical trick (I don't know its name in English): You impute that I claimed things which I never said - of course, then it is easy for you to prove that these things are wrong. What, like saying my point was only about saving two tokens? I _never_ suggested to use code from stone-age for ebuilds You did as far as I am concerned. Careful please, both of you. This bit looks like it could be headed personal, and I don't believe that's in the interest of anyone. Eh, I feel that's slightly taken out of context, in that we both smiled at each other during the course of the discussion, and I wouldn't have made such a long post if I hadn't both respected Vaeth and thought it was a technical discussion (now that we have project. I'm cross-posting this for for those who only follow dev; please follow up to project if you wish to comment further.) I did thank him at the end too, to keep it civil. Having said that, you're right that it could be read like that, and I applaud your acting to stop any suggestion of it. Guess I was being a bit Germanic ;-)
[gentoo-dev] Re: Re: Default src_install for EAPI-2 or following EAPI
Thomas Sachau wrote:
Ulrich Mueller schrieb:
And I still don't see why we would need the most general solution for
a *default* function. There's always the possibility to write your own
src_install() for the few ebuilds that need it.
I aggree with Ulrich in this case.
As I said; generality in lib functions seems like a useful thing. There's a
quote I read from what is imo a classic computing text[1] (from the 70s,
never seen it referenced in any papers or anything):
Why do we never have time to do it right,
but always plenty of time to do it over.
if emake DESTDIR=${D} install || einstall ; then
missing Don't those braces make it tricky.. ;p
Any more comments? Good? Bad? Interested?
Given that we're okay relying on BASH, I don't think we should be scared to
use BASH effectively. Gentoo ebuild.sh should be a shining example of how
BASH is done, after eight years, not something that makes #bash folk laugh.
(I know this to be true, as when I started learning BASH, I tried dropping a
few of the lines in the channel to find out what was going on. It amazes me
that #bash is not mentioned in any of the Gentoo developer documentation,
afaict.)
In this case, you're saying oh anyone who wants something that copes with
all filenames can do their own. IOW to do it right, we'll have to do it
over, further down the line.
BASH includes the facilities to do it right, as part of its design.
[1] Program Style, Design, Efficiency, Debugging and Testing van Tessel
(Prentice-Hall, 1974)
[gentoo-dev] Re: Re: Default src_install for EAPI-2 or following EAPI
Vaeth wrote:
Steve Long wrote:
Thomas Sachau wrote: [...]
[[ -n ${DOCS} ]] dodoc ${DOCS}
[...]
It might be wise to use an array for DOCS there
Since I have now seen suggestions for using arrays unnecessarily
at least twice (see also
[RFC] Ability to pass arguments to src_configure/src_compile
but I am only speaking about the usage of _arrays_ here),
let me remark that the more clever way to this is
[ -n ${DOCS} ] eval dodoc ${DOCS}
eval is _not_ clever. Try: /msg greybot eval
..or check http://wooledge.org:8000/BashFAQ/048
This way, people can simply quote as they like:
DOCS='filename with spaces' filename_without_space doc/*
Yeuch.
or also
DOCS=just_one_filename_without_special_characters
You don't need quotes there.
or also - when Push from /usr/bin/functions-eix.sh is used
(which might be implemented simpler without using other functions):
Push DOCS 'filename with spaces' filename_without_space ${S}/doc/*
Or just do DOCS+=(foo/* someFile 'some other File') at any point.
BASH arrays will cope with *any* character apart from NUL, which isn't
allowed in filenames. Can you _guarantee_ the same?
For instance, what if some crazy designer puts a file called:
Vaeth's Latest Hits
..in that doc dir; what happens after the Push function has been called and,
only at a later stage, the eval is run on the result of that glob
expansion?
Not only has this the advantage that it is POSIX (and thus does not
force ebuilds to use the particular shell bash - a policy which perhaps
some day might be changed: It is dangerous to depend on a particular
implementation),
I'm not getting back into that discussion, since we had the same one over a
period of months already. Ebuilds require BASH; get over it. If we could
move ahead with actually using BASH properly (and cleanly) it would be
nice. BASH is as portable as GNU make is, and you clearly have no issue
depending on that, and Python or C++.
BTW, POSIX sh doesn't need ${DOCS} or ${S} either, you're just wasting
characters.
the array-less solution is also much simpler to
implement, easy to understand from the source, and clearer in usage.
Not to me it's not, it looks awful, to read and to type, as well as being
fragile.
Furthermore you're bringing eval into the script new people are going to
look at to learn from (it's core functionality, fulfilling a basic task)
which is dangerous from a long-term pov, imo. Leave aside having to
maintain that cruft.
Case distinctions like
if isArr DOCS; then
(([EMAIL PROTECTED])) dodoc [EMAIL PROTECTED]
else [[ $DOCS ]] dodoc $DOCS
fi
are just awful.
Actually if you factor out that isArr is a utility function (exactly like
Push) that code is very easy to follow, as well as coping with all
filenames, and itself would be part of a lib function. The only reason to
have the check is for backward-compatibility, or to allow people to use
whichever they feel most comfortable with.
One might not know how to count/use arrays in BASH, fair enough; that's how.
Given that basic knowledge[1] of the tool used to write ebuilds since the
very beginning, I cannot see how that is hard to follow.
I'm willing to bet your sh scripts aren't really as portable as you think.
If you want to see how portable sh is done, read:
http://sources.redhat.com/autobook/autobook/autobook_210.html#SEC210
(all of it) and then try to persuade us that we should be writing ebuilds
like that.
If you want to do that kind of thing, much better imo to do another type of
ebuild, eg a pbuild using Python, and only call sh when absolutely
necessary, if at all.
BTW, thanks for eix; it's a lovely utility.
[1] http://wooledge.org/mywiki/BashFAQ/005
[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
Ulrich Mueller wrote:
On Mon, 22 Sep 2008, Kent Fredric wrote:
find /usr/share/doc/ -wholename * *
/usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2
Yes, and if you look into src_install of the ebuild, it does:
dodoc doc/*.txt
Well at least we've established that it can and does happen.
So a simple dodoc ${DOCS} with DOCS=... doc/*.txt ... would work
even in this case. No need for arrays.
That works for that specific case, yes, but it's still not a general
solution, which is what BASH arrays were invented for. For instance, an
ebuild author cannot specifically include a file with spaces, and ignore
all the other files in the same directory.
To show what I mean, given this one-liner in a terminal:
args() { (($#)) || return; echo $# params:; local i n=1; for i; do
echo $n: $i; let n++; done; }
..try these (where doc is a subdirectory of your current folder, and mem*
matches some files in it):
DOCS=doc/mem* foo; args $DOCS
DOCS=doc/mem* 'foo bar baz'; args $DOCS
DOCS=(doc/mem* 'foo bar baz'); args [EMAIL PROTECTED]
Globs work fine for a function call, or indeed for adding to an array. As
soon as you try to indirect via a variable, it has to be an array if you
want to be safe with filenames, for the general case. The same applies to
dynamic commands. See:
http://wooledge.org:8000/BashFAQ/040 and:
http://wooledge.org:8000/BashFAQ/050
Given that we're using BASH, it seems strange to preclude useful constructs.
It's a bit like telling someone to use Python without dicts (or even lists,
given how basic arrays are to virtually every programming language.) It's
much simpler to write scripts that will work with anything, and be able to
rely on them, than have to fix or work round them later.
[gentoo-dev] Re: Making built_with_use die by default with EAPI 2
Petteri Räty wrote: When EAPI 2 goes live built_with_use should probably die for most cases. Are there valid use cases for built_with_use that are not covered by the use deps in EAPI 2? If there are we could add a switch like --noeapi2die to it. It would be nicer imo if we just added --or-die as a general switch to those functions we can (and look at sorting out the subshell die thing for -exec externals.) That way the decision to die or not would be down to the ebuild author and always explicit from looking at the code.
[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
Ulrich Mueller wrote: On Sun, 21 Sep 2008, Steve Long wrote: That works for that specific case, yes, but it's still not a general solution, which is what BASH arrays were invented for. For instance, an ebuild author cannot specifically include a file with spaces, and ignore all the other files in the same directory. The better solution would be to rename a such strange files ... How about an edetox? ;-) Heh, I like the name (it brings lots of ideas to mind, none of them very achievable ;) but you get into the issue that you're changing the upstream naming, which goes against the principle of source transparency I personally love. It makes dealing with upstream projects much easier. And I still don't see why we would need the most general solution for a *default* function. There's always the possibility to write your own src_install() for the few ebuilds that need it. ? Generality for lib functions seems like a desirable attribute to me. If we handle the general case with the defaults, it means less need for anyone to write more code, allowing them to focus on the interesting stuff and keeping the tree smaller. If we never have to worry about whether the base will cope with filenames, and only about quoting our own stuff, it makes development quicker.
[gentoo-dev] Re: Re: Re: Default src_install for EAPI-2 or following EAPI
[Sorry for length]
Vaeth wrote:
Steve Long wrote:
Vaeth wrote:
let me remark that the more clever way to this is
[ -n ${DOCS} ] eval dodoc ${DOCS}
eval is _not_ clever. Try: /msg greybot eval
..or check http://wooledge.org:8000/BashFAQ/048
This is not at all related with my remark:
We were speaking about the variable DOCS, which is supposed to be
defined by a package author, not by an unreliable source.
Of course, unreliable data here may allow execution of arbitrary code,
but the package author can execute what he wants anyway.
My point wasn't about security so much as the fact that the author has to
worry about how the filenames will be interpreted. You state that
saying it will be eval'ed is enough. I disagree, as it makes it trickier
to handle.
This way, people can simply quote as they like:
DOCS='filename with spaces' filename_without_space doc/*
Yeuch.
Well: DOCS=('filename with spaces' filename_without_space doc/*)
I cannot see much difference: ( ) vs. would optically IMHO not be a
reason to discuss, but the former works only in bash, the latter
practically everyhwere (and so shell programmers should be used to the
latter notation anyway).
That's the thing though; most Gentoo devs don't appear to be shell
programmers, and certainly not POSIX sh ones. BASH is simply much more
convenient to work with, especially if you are used to another language
(that has arrays for example.) That convenience adds up to saved time and
cleaner code.
Again, your formulation only works with eval. It doesn't work easily as a
generic thing; it requires thinking about, mental effort from devs who are
already overstretched. I guess it comes down to the debate over saving
programmer time vs CPU time.
or also
DOCS=just_one_filename_without_special_characters
You don't need quotes there.
This is true, but I wanted to show the way most people will use it.
Sure, but people should also be learning when quotes are needed and when
not; that is fundamental to shell-scripting after all?
or also - when Push from /usr/bin/functions-eix.sh is used
(which might be implemented simpler without using other functions):
Push DOCS 'filename with spaces' filename_without_space ${S}/doc/*
Or just do DOCS+=(foo/* someFile 'some other File') at any point.
So the difference is saving two tokens. Is this worth to cement
bash-dependency forever in many scripts?
No, my point was that it's part of basic BASH syntax, so anyone looking at
it who knows BASH knows exactly what it does, without having to dig through
an eclass or the like to make sure. It's cleaner to work with in the lib
code too.
BASH arrays will cope with *any* character apart from NUL, which isn't
allowed in filenames. Can you _guarantee_ the same?
Yes, Push does _guarantee_ the same. It is actually rather simple to
implement: It puts its argument in '...', separated by spaces,
but replaces ' in the arguments before by '\'' (the last part is a bit
tricky to do in POSIX [although not really hard - only in functions-eix.sh
this is lengthy, because a more general replacement function is used
there]. For the time being, I would not even argue against implementing
Push in a sourced script in bash: This is only one place to change if one
wants more compatibility later on).
Cool, I've seen that trick in makefiles (kernel uses it for echoing cmds
iirc.) If you're stuck with a shell that only implements a stone-age
standard, designed to allow a base common-denominator 15 or 20 years ago,
fair enough ;p
Ebuilds require BASH; get over it.
My remark concerning arrays was meant to be general, not specific for
ebuilds/portage only (although I couldn't find a passage in the bible
where god claimed that ebuilds have to require bash.
Yes, hyperbole aside: ebuilds have been built on BASH from the start.
Actually, 99% of
the ebuilds would not need bash, if they would be modified in a completely
trivial ways (for the remaining 1% it would need a bit more work)).
If one encourages people to write ebuilds compatible, maybe even for
portage some day a change is realistic (although I am completely aware
that this is not a reasonable project for the near future).
The thing is those changes make the code harder to read and maintain, which
matters for the target scripters. It's important to be able to look at the
script and tell what it does quickly; it's also important to be able to
write and update it quickly and relatively easily.
BASH is as portable as GNU make is, and you clearly have no issue
depending on that, and Python or C++.
Do you know which shell might be preferrable in 5 years or 10 years?
Bets are good that thos shell will at least support POSIX;
bets are worse that this shell will support the bash-specific
treatment of arrays.
ksh, zsh and bash all have arrays. Since POSIX came along, the development
(which moves forward, remember) of most next-generation shells (ie
[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
Thomas Sachau wrote:
I see, we have a default src_unpack and a default src_compile but a
default src_install is still missing. Here is my suggestion (taken and
modified from bug 33544):
src_install() {
if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
emake DESTDIR=${D} install || die emake install failed
You need to quote $D there, eg: DESTDIR=$D as it's a parameter to a
command there, not a temporary export (as: DESTDIR=$D emake.. would be.)
[[ -n ${DOCS} ]] dodoc ${DOCS}
else
einstall || die einstall failed
[[ -n ${DOCS} ]] dodoc ${DOCS}
fi
}
Any comments?
It might be wise to use an array for DOCS there, so that filenames with
spaces are dealt with correctly. (I'm thinking of all those lovely GUI
apps.)
To keep compatibility with space-separated values, I use this function:
isArr() [[ $(declare -p $1 2/dev/null) = 'declare -a'* ]]
(Yes I know, it's fugly.)
So this kinda logic deals with both:
if isArr DOCS; then
(([EMAIL PROTECTED])) dodoc [EMAIL PROTECTED]
else [[ $DOCS ]] dodoc $DOCS
fi
(There's no need to repeat it, just move it to after the previous if.)
That can easily be initialised with a glob, eg DOCS=($S/doc/*) (although I
recommend nullglob if doing so.)
[See http://wooledge.org:8000/BashFAQ/073 (half way down) if you need to
strip prefixes or the like.]
[gentoo-dev] Re: Re: Request for feedback on GNU Patch change
Fabian Groffen wrote: On 17-09-2008 10:21:17 +0200, Santiago M. Mola wrote: Why not simply alias patch=gpatch in profile.bashrc? See the FreeBSD profile for an example. I'd like to package portage for OpenSolaris and have it just drop-in work so modifications like what you suggest wouldn't be required. You'd still need to create an OpenSolaris profile. While you're at it, you can create a profile.bashrc with the required modifications. I don't see any reason to not do the gpatch change, but it looks like unecessary to me because you already have simpler ways to solve the problem. So, requiring others to do a significant useless amount of work when you can solve it with just a line is not fair. From some experience, I can tell that an alias is not sufficient to cover all cases, and will result in random failures because you only notice too late patch is used and not gpatch. alias only works for stuff that bash parses as a command on tokenisation. So it won't work for anything called via a variable, or find -exec/xargs. (Note also the standard way to get round an alias: \foo or `command foo'.) By the way, I'm against this stuff. I rather see a PATH solution involved. Portage already has a DEFAULT_PATH, and if someone refuses to install patch, one could always use a special directory with symlinks to the g-versions, e.g. patch - /usr/sfw/bin/gpatch such that Portage/eclass/ebuilds don't have to bother about this at all. I agree. PATH+=':/blah/bar', or PATH=/blah/bar:$PATH if you want it considered first. The alternative would be a variable for every utility that could conceivably be called, and then every ebuild would need to use those, which is a maintenance nightmare imo. I guess you could ban use of -exec/xargs but I don't think that's likely ever to happen.
[gentoo-dev] RFC: Bug 217042: enewgroup/enewuser in pkg_setup()
Just wondered what's going on with this one; is it waiting for impl of GLEP 27 or something? Would it be wise to update the documentation as requested, in the meantime? http://bugs.gentoo.org/show_bug.cgi?id=217042
[gentoo-dev] Re: RFC: Glep 55 use case: moving slot to file name
Petteri Räty wrote: Icedtea has two release tracks. One for the 1.7 OpenJDK code base and one for the 1.6 code base. They have independent version numbering so they can have collisions. By moving the slot to the file name we could have icedtea-1.2:1.6.ebuildN and icedtea-1.2:1.7.ebuildN. This particular situation can be worked around of course but it might also be better to keep the slot in the file name any way because I often find myself needing to know the slot of an ebuild (adjutrix -k of course already does this for me quite nicely). Debian-style epochs are a _much_ cleaner solution: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version (eix does quite nicely at displaying slots, too.)
[gentoo-dev] Re: Re: Re: News item: World file handling changes in Portage-2.2
Dale wrote: Holger Hoffstaette wrote: On Wed, 10 Sep 2008 11:38:56 +0100, Mike Auty wrote: Marius Mauch wrote: Maybe the best solution is to drop the non-prefixed versions of 'world' and 'system' completely Deprecating the old syntax sounds like a sensible action to get people shifted onto the new system. I imagine it would work very similarly to emerge info at the moment? Speaking purely as a user, from a usability perspective it's a horrible idea. Don't make me remember special things. To me there is no discernible difference between system and @system, except that I have to remember to prefix the latter over and over again. Different things need different names. Well you might well have other sets, like @kde4 or anything you like, which would be up to you to maintain as a user. Doesn't portage have more pressing problems? In the last 6 years of using Gentoo I cannot remember a single instance where the difference between system and world even mattered to me from an operational point of view. I've seen it most for new installs, where the user might use 'emerge -e system' to get the base stuff built for their specific CPU, followed by 'emerge -uDN world'. For major gcc upgrades, it's common to want to use 'emerge -e system' first followed by 'emerge -e (world - system)' which is an approach emwrap[1] pioneered. Personally I don't see much point to the first -e system, since major gcc upgrades are really only a breakage issue for C++ apps (paludis has in the past stopped working after a gcc upgrade of this sort, which can be an issue if there is no way to use another package manager to get it rebuilt, which is the recommended config.) update[2] does the recommended (based on various user posts, can be tweaked ofc) order for any toolchain packages (extended def'n if $compiler is in the list, including things like automake if there's a new version) which appear for any emptyTree build, prior to the rest of the list. This makes 'update -e world' pretty good for gcc upgrades (it'll skip a major gcc upgrade in other circumstances, so that your system isn't left inconsistent.) Also speaking as a user, I confuse pretty easily and you can ask anyone on gentoo-user about that. However, I see the difference between @system and system. The same for world or at least a good idea anyway. Afaict there is no difference between system and @system. The question is whether world and @world can coexist with different meanings, provided the user hasn't run 'emerge system' (or @system) which atm makes the @system set part of @world. (Confused? You will be ;) This is useful for user- or profile-defined sets, eg for the earlier example, emerge @kde4 would make the @kde4 set part of @world (by reference; @kde4 is put into world, not the individual packages from it, so it can be maintained as a separate list.) A user wishing to avoid @system being part of @world can set world-candidate=false in /etc/portage/sets.conf, to keep using @system and @world separately. (see /usr/share/portage/config/sets.conf for examples.) I have to also say that I like being able to type in emerge -uvDN world and letting my system upgrade everything that needs upgrading. It's simple, easy and not so much typing. I can somewhat understand the need for @system and @world but think both can live together pretty well. Yeah I agree; I don't think every user is going to be interested in sets, and I see it as a minor, encapsulated, special-case in code terms, whereas it has pretty major impact on end-users (and will cause support hassle.) As soon as you type @foo you know you're in set-land. I do think there should be some sort of notice for those users that do not follow -dev, -user and/or the forums tho. That has been a issue for a long time. There does not seem to be a clear cut way to inform all Gentoo users except during a emerge. Yeah although the news item thing did get accepted as a GLEP, and afaik the package managers support them, I've never actually seen a news item in the console. Maybe I'm doing something wrong again.. Thing is, emerge -uvDN world will do the same as it always has from my understanding. Well it'll tell you that usage is deprecated, and until you emerge system (or @system) it won't be considering those packages as part of world. (I believe it will be added automatically on upgrade from 2.1 to 2.2 for stable.) Once you do, it'll require a bit more to do an emerge -e @system emerge -e @world. If you are keeping them separate, you'll need emerge -uDN @system @world, aiui. Hence the desire to keep 'world' meaning what it always has, irrespective of the sets.conf. As I said before, I consider this minor tweaking to cli usage for major new functionality, which I think is really cool stuff. Whichever way the portage devs decide to go, kudos to them for what they've come up with. [1] http://forums.gentoo.org/viewtopic-t-282474.html [2]
[gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
Marius Mauch wrote: On Wed, 10 Sep 2008 01:43:45 +0100 Steve Long [EMAIL PROTECTED] wrote: Marius Mauch wrote: Second for the suggestions on how to handle the transition: - treating 'world' and '@world' differently is a no go from my POV. One of the main reasons to implement them as sets was to remove special case code in emerge, so I'm quite opposed to adding new special cases instead. And I'm quite sure that such a separation would cause confusion, and some isues regarding (end-user) documentation. We're talking about one special case in the command-line processing, to support the existing usage that all our users are used to. It adds practically nothing in execution time, simply expanding to @system @world, and means that users who don't want to know about sets, or are not thinking in set terms at the time of using emerge, will get the result they expect. It also means we'd indefinitely have to carry another special case around for legacy reasons (removing it later would be even more painful than doing the switch now). You know, those are the things we want to get rid off, as they really make our life harder in the long run. YOu may consider it trivial in this cse, but these things always look trivial when you're adding them, and you curse about them when you have to modify the code later on. I know exactly what you mean. However, this special case *will* save Gentoo a great deal of support hassle, imo at least, and is confined to the option-parsing code. It's perfectly well encapsulated and will never `leak' into any of your dependency resolution or set-handling code. Maybe the best solution is to drop the non-prefixed versions of 'world' and 'system' completely I'm fine with system ;) although as outlined, I don't see that it can add maintenance to anywhere but the option parser, and only then if what you want the end-user to update by default changes. I see that indirection as an added bonus, since it means you can easily maintain a cli api for end-users (or tired admins) as opposed to power-users or devs, and the sets [or indeed options] used can change over time (since we're discussing long-term maintenance) without the same switchover hassles as now. There'd be zero need to reeducate the end-users, and interested ones would be following dev, or would read about any new set in GMN.
[gentoo-dev] Re: News item: World file handling changes in Portage-2.2
Marius Mauch wrote: Second for the suggestions on how to handle the transition: - treating 'world' and '@world' differently is a no go from my POV. One of the main reasons to implement them as sets was to remove special case code in emerge, so I'm quite opposed to adding new special cases instead. And I'm quite sure that such a separation would cause confusion, and some isues regarding (end-user) documentation. We're talking about one special case in the command-line processing, to support the existing usage that all our users are used to. It adds practically nothing in execution time, simply expanding to @system @world, and means that users who don't want to know about sets, or are not thinking in set terms at the time of using emerge, will get the result they expect. Also it makes it easier for users who don't want @system included in @world, eg for easy use of -e @system followed by -e @world. Though honestly I don't think this issue is as big as some other people make it. People might miss some updates. The same would happen if we remove packages from @system, or people switch profiles (so @system changes). Or you could just do as above and people wouldn't miss any updates, and you'd have less support burden from users who aren't bothered about sets, who can carry on using their systems as they always have.
[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile
Duncan wrote: Ciaran McCreesh [EMAIL PROTECTED] posted Having to write an ebuild just to install something in a package manager friendly way and be able to uninstall it cleanly later is a defect, not a feature. I've always rather liked that I can tell someone in -dev-help or -chat If you can build it from source, it's simple to make an ebuild. A lot of the time you don't even need anything more than a few bash variables. So in that sense I consider asking someone to do a little bit to be a good thing, since it gets them over the first hurdle for contributing (and gives them a Gentoo buzz.) Impressively stated, but it still doesn't get past the simple open accessibility bit, letting the user-sysadmin do simple real-time modifications of how the package appears on and interacts with the individual system. I agree with the spirit of what you're saying. Taking the detail from your other post: it may be optional, but that doesn't help much if all the simple ebuilds he finds to crib from end up using the pre-knowledge required vars, leaving him nothing simple to crib from without that knowledge. The accessibility level will have been reduced if this happens. Yeah, but I don't think this would become the overriding method. Even if it did, in terms of what developers, or indeed automated tools, produce, the old method would, of necessity, always be allowed, and should be documented in the stages of an ebuild part of a devmanual. Understanding of the classic method is _required_ to make use of the declarative one, which is just syntactic sugar for the classic econf/configure parameters. (I still think the original patch is better, ofc ;)
[gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh wrote: On Mon, 08 Sep 2008 22:40:37 +0100 Steve Long [EMAIL PROTECTED] wrote: * should be treated as being very quickly installable * should be treated as having zero cost for installs Both of which follow from installs nothing. Or would you disagree? No, they're separate properties, with different implications. Sure I understand that there are other properties which need to be addressed, and can be in APIx, but for the classic virtual as defined, which may be extended to be considered as having the associated cost of installing its deps in pkg-selection terms, or not, the given notation suffices. Consider, for example, a split baselayout-style package. There could be a skeleton-filesystem-layout package that does all its work in pkg_* functions (to avoid permission and empty directory problems that come from installing directories via the normal methods). It would install nothing, but should not be considered for either zero-cost property. Well, if that package spat a load of directories onto my system I'd personally consider it as installing something, and I'd expect those directories to be listed in its contents. Or, for the reverse: a package that merely installs a simple control file that enables functionality in another package may well be best considered as zero-cost for package selection. If a package depends upon || ( big-scary/processing-package simple-little/plugin-for-foo ) and you already have foo but not plugin-for-foo installed, the right thing for the resolver to do would be to suggest plugin-for-foo. Sure. As for the quickly installable property, plugin-for-foo might not possess it -- for example, vim plugins generally do a vim tag regeneration upon pkg_postinst, so they're not 'quick' to install even if all they do is provide one text file. Great, thanks for outlining some use-cases for the split properties. If virtual turns out to need a slightly different set if and when the extended properties are brought in, that can easily be done. I don't see that there's any conflict.
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Joe Peterson wrote: Ciaran McCreesh wrote: Except it doesn't. A virtual ebuild: * installs nothing * does nothing I'd say that virtual does indeed do something: it pulls in other packages. * should be treated as being very quickly installable * should be treated as having zero cost for installs Both of which follow from installs nothing. Or would you disagree? The property proposed corresponds to only the last of these. Still, the term virtual fits the spirit of the idea well. Indeed, and it is well-understood.
[gentoo-dev] Re: Re: [RFC] EAPI 2 Draft
Alec Warner wrote: On Sat, Sep 6, 2008 at 4:43 AM, Steve Long [EMAIL PROTECTED] wrote: Christian Faulhammer wrote: Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. One needs exceptions for all kind of systems, for example I had to workaround Trac which adds ?format=raw to a tarball URI. There seems to be a solution in Trac as the guys from fedarahosted fixed the two I needed (tmpwatch, mlocate). So the - operator is quite useful and I agree with David that the functionality is doubled. Clearly src-uri transformation is useful. Others have given examples of how it would be useful to an eclass. Irrespective of how the actual transform is done in the ;sf=tbz2 case, both _are_ valid use-cases. As such I don't see any reason not to put it in the EAPI. Future extensions can be trialled in eutils, and these can both be allowed syntax for other package managers to comply with (one implementation has already been given) and ebuild devs to feel comfortable using in the Gentoo tree. Why slow the innovation down? It's good enough for use as-is. Because then we have to wait for all the PM's to implement this magical code; where if we put it in eutils we can use it right now (and most overlays can use it too). 'Why slow the innovation down?' :) Eh? I thought it was for the portage team to define the EAPI for Gentoo, published so that others can interoperate? And how are other Package Managers going to feel if they have to keep checking eutils for what it does to stay current with the tree, as opposed to looking in the EAPI doc? This is wandering into -project territory however, imo, since there's no _technical_ reason not to allow the proposed usage in the EAPI. All I've heard so far is we might want to extend it later.
[gentoo-dev] Re: Re: [RFC] EAPI 2 Draft
Thomas Anderson wrote:
On Sat, Sep 06, 2008 at 12:43:12PM +0100, Steve Long wrote:
Christian Faulhammer wrote:
Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file
name.
One needs exceptions for all kind of systems, for example I had to
workaround Trac which adds ?format=raw to a tarball URI. There seems
to be a solution in Trac as the guys from fedarahosted fixed the two I
needed (tmpwatch, mlocate). So the - operator is quite useful and I
agree with David that the functionality is doubled.
Clearly src-uri transformation is useful. Others have given examples of
how it would be useful to an eclass. Irrespective of how the actual
transform is done in the ;sf=tbz2 case, both _are_ valid use-cases.
Sure they may be valid use cases, but the issue is whether the
;sf=tar.bz2 code is duplicated from '-'. I don't see any reason why you
can't use '-' to handle ;sf=tbz2, so they are duplicated. Since '-'
can be used in more circumstances(SRC_URI=http://foo.com/2.3/foo.bz2
- ${P}.tar.bz2 comes to mind), we don't need ;sf=tbz2.
You're confusing the code which implements, with the API thus provided. It's
totally irrelevant whether the same code handles the functionality or not.
(That's what encapsulation is about.)
[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile
Ben de Groot wrote: It may be 2 lines less, but it is 42 characters more. Plus, I dislike caps. :-p Well the original patch used DEFAULT_CONFIG_ENABLE and DEFAULT_CONFIG_WITH and didn't invoke any subshells. I'm not sure what the thinking behind changing it was, unless it was a straight lift from paludis. As for caps, that's kinda standard within ebuild-land if something crosses functional boundaries, but I agree they're ugly ;) (In Bash, I'd only use them for constants or env vars.)
[gentoo-dev] Re: FHS compliant KDE install and multi-version support
Jorge Manuel B. S. Vicetto wrote: The next step was to use a kdeprefix use flag[2]. This flag no longer touches the SLOT that is set to 4 for all kde-4.X versions. It only determines if the package will be installed under the FHS compliant location (/usr) or under the old location (/usr/kde/version). This however means the users will no longer have the option to have more than one kde-4.X version installed. If that stops _all_ users from doing so, I'd vote against. I've been thinking on a different method. With this method [3], we would keep using the major.minor slots (4.1, 4.2, etc) so we also wouldn't break the invariancy. We would allow users to select whether to have an FHS compliant install or not (the way to allow that still needs to be discussed) and we would set the prefix based on that. In case the user wants an FHS compliant install, the eclasses would block all kde packages on other slots - except 3.5 (uses other eclasses) and the live versions (for the above reason that it will always be installed under /usr/kde/live-version). One way to decide whether to install on an FHS compliant location would be to add a use flag, but I don't think adding that flag for 200+ ebuilds makes sense as it doesn't make sense to have 1 version of some packages and possibly 2 or more of other packages. Perhaps FHS is more of a feature than a USE flag? It certainly could apply to other packages, and as you say adding and maintaining the USE flag to/for so many ebuilds is a bit of a pain. So, what am I after in this email? After having an internal discussion and then opening it up to users in #gentoo-kde and a few other people on #gentoo-portage, it was suggested I sent a mail here to open this discussion to everyone and to present the case in a more clear manner. So, can anyone suggest a good way to accomplish what were trying to do? At least a better solution than the ones I've presented above? Just a thought, but this sounds an awful lot like a prefix ebuild. Is there any relevance from grobian's work? Wrt to the blocks, it doesn't strike me that major iff the user has set FHS in FEATURES (or w/e the mechanism is) since in that case they will be on the manage everything for me, for this install track.
[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile
Vaeth wrote: The point is that in contrast to shell code you need additional pre-knowledge to read or write it. True. the syntax looks fine and the syntax is in fact still bash. I do not want to start a discussion now whether this is implicit semantic or sort of an extended syntax - it depends on the point of view. But in any case it involves new (and actually redundant) keywords in the ebuild. Yes it's extended syntax if you like. The knowledge needed to write or read ebuilds should be kept as small as possible. Agreed. This is similar to the make it look like as much like a from-src build as possible argument. I would question just how much of a burden this adds to the knowledge required to write an ebuild, however.
[gentoo-dev] Re: [RFC] EAPI 2 Draft
Christian Faulhammer wrote: Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. One needs exceptions for all kind of systems, for example I had to workaround Trac which adds ?format=raw to a tarball URI. There seems to be a solution in Trac as the guys from fedarahosted fixed the two I needed (tmpwatch, mlocate). So the - operator is quite useful and I agree with David that the functionality is doubled. Clearly src-uri transformation is useful. Others have given examples of how it would be useful to an eclass. Irrespective of how the actual transform is done in the ;sf=tbz2 case, both _are_ valid use-cases. As such I don't see any reason not to put it in the EAPI. Future extensions can be trialled in eutils, and these can both be allowed syntax for other package managers to comply with (one implementation has already been given) and ebuild devs to feel comfortable using in the Gentoo tree. Why slow the innovation down? It's good enough for use as-is.
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Duncan wrote: Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 26 Aug 2008 14:20:44 +0100: On Tue, 26 Aug 2008 06:39:38 + (UTC) Duncan [EMAIL PROTECTED] wrote: But I think virtual works just fine for kde-base/kde, too, if one simply reads it literally -- it's a virtual package in that it doesn't install anything itself, even if it's a meta-package [...] So what does 'virtual' actually mean then, and how is it related to the defined behaviour of this property? I'm unsure of whether that was intended to be a rhetorical question or not, so taking it literally... Yeah, I think the original mail outlined the meaning quite explicitly, although this is good, perhaps for user documentation: Opposite of real or physical. So a virtual package would have the essence and effects of a real one (dependencies and the like) but not be real in some way (here, zero- install-cost, or more correctly, only the install cost of the dependencies). More directly, a package that doesn't actually install anything itself, only having dependencies that ensure other packages are installed. In original Gentoo usage, virtual packages didn't have ebuilds at all, but referred to dependencies that several different packages could provide, with the the profile generally specifying a default. Now many of them have ebuilds, but the general idea of not installing anything directly themselves, only thru dependencies, remains. This is equally true of the original no-ebuild virtuals, those ebuilds in the virtual/ categories, and various meta-packages such as kde and kde-meta. Thus, they fit the broader defintion of virtual in a literal sense, regardless of where they are located in the category tree. I concur that it makes a lot of sense, fitting in exactly with the meaning originally given. That it means 'zero-install-cost' is neither here nor there imo; 'virtual' is a well understood terms for the same thing: an ebuild that doesn't in itself install anything. That kde and kde-meta are changing doesn't matter to the general suitability of the property for other meta ebuilds, although it'll be interesting to see if sets become the new method. Also, as outlined wrt live-cvs, specialisation of the base property is envisaged. I therefore believe I like just moving them all to a *virtual*/ category better, thus obviating the need for that particular property in the first place. Yeuch ;) I agree with Zac on this aspect: existence of meta-packages in the java-virtuals category [5], among others, makes it useful to introduce the virtual property as a means to identify these ebuilds. Note that some packages, such as x11-libs/qt [6], exhibit this property for some versions and not others. So, in some cases it may be useful to be able to specify the virtual property separately for different ebuild versions. It's clearly something that can be useful across the tree, and can apply to an ebuild as opposed to a package. Forcing a category (or a pkgmove which is a pita aiui) seems inelegant (and doesn't enable the second use-case); the property is far more appropriate, and as you say, 'virtual' is less confusing for a user than 'zero-install-cost', especially within Gentoo. PROPERTIES seems like it's going to be a very handy variable.
[gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh wrote: On Sat, 30 Aug 2008 10:59:41 +0100 Steve Long [EMAIL PROTECTED] wrote: I concur that it makes a lot of sense, fitting in exactly with the meaning originally given. That it means 'zero-install-cost' is neither here nor there imo; 'virtual' is a well understood terms for the same thing: an ebuild that doesn't in itself install anything. Except that that's not what it's being used to mean. It's being used to mean the cost of selecting this when doing dependency resolution cost analysis is zero, which is an entirely different thing. So it's zero-resolution-cost now? Yes, that *is* different (although I'd use free-resolve. free is well understood as often meaning zero-cost, which isn't a phrase most English-speaking people use. It only has meaning within the PROPERTIES variable, so it's not going to clash with anything.) 'Since new-style virtuals are a type of meta-package, I'd prefer that we introduce some type of package metadata into the EAPI that distiguishes meta-packages (those that do not install anything) from normal packages.'[1] It's clearly something that can be useful across the tree, and can apply to an ebuild as opposed to a package. Forcing a category (or a pkgmove which is a pita aiui) seems inelegant (and doesn't enable the second use-case); the property is far more appropriate, and as you say, 'virtual' is less confusing for a user than 'zero-install-cost', especially within Gentoo. Users don't need to see it. Heck, most developers don't need to see it. Well any dev using it will do, and I believe most of them start out as users. Anyone reading the ebuild will see it, and the fact that it's a well-understood term, within Gentoo at least[2], makes it easier for the PM user-base to work with. It's a cultural people understand this already point as opposed to a technical make-it-as-explicit-as-we-can one. That it's easier to scan and type is a bonus. [1] http://bugs.gentoo.org/show_bug.cgi?id=141118#c5 (bug has previously been cited as part of the motivation for this property.) [2] Of course for a new project, one could use whichever term one felt like, since users would be expecting a divergent codebase. Heck, it might even be worth changing names of stuff just for the sake of appearing shiny (or to kill backward-compatibility, or make it harder for people to make the mental switch back. Every little helps.)
[gentoo-dev] Re: Re: Re: Re: [RFC] What features should be included in EAPI 2?
Alec Warner wrote: At least one has...do you want to vote for each feature? What will it take to convince you? It's not up to me, and I've already conceded on IRC that the consensus is against me (just letting others know); that's life *shrug* (The one missing is a src_fetch_extra or somesuch, for use by the scm eclasses. But that wants special handling, and is probably best left to another EAPI...) Yes, a defined, configurable API for dealing with any version control would be useful, though your minion seemed to argue against it in #-portage. I can think of a couple of things that would be more useful to end-users: pkg_check for interactive ebuilds (eg license acceptance or media access), proper support for cross-compiling, integration of prefix, better handling of overlays, and of binpkgs.. Your comment is arguably about feature prioritization; not about whether a given feature is necessary. If we have two orthogonal features A and B; you can't argue that A is necessary and B is not because A is more important to work on; the only thing you have succeeded in doing is arguing that A should be done first. My point was that pkg_check has been requested from years ago, and focus (on the ml, not in terms of what gets done on portage) over the last year or so seems to be much more on things which make it easier for devs to work on live ebuilds (not surprising with kde-4) not on stuff which would make the end-user experience easier, which is what would bring more new users (and thus new devs) in. Both are important, but making your users' lives easier means less support burden, which means you get more time to play with shiny new (aka 'broken') code. Further, I think it would be cleaner if the package manager had a defined configuration to deal with any version control system via an eclass, meaning adding a new one would simply be a case of adding the .eclass to the tree and the eclass name to a profile, with no changes at all required in the mangler, beyond support for the base API (which is in any event handled by bash.) Eclass versioning would be nice too. In maintenance terms (when looking at the lifecycle of an ebuild) I don't see the need, since there is no unpacking required from a vcs pull. Once it's made into a normal ebuild, any preparation would necessarily require review and might not be needed at all. Call the function what you like (or add a new phase with the hooks) it's still logically one point in time. For a live ebuild it's to prepare the src, for a normal one to (possibly) unpack and prepare. src_configure is a logically distinct action which warrants a new phase, since the e*conf call in compile makes retrying a long build (without having to recompile stuff which doesn't need it) much more difficult; its absence prevents full use of make. Prepare does not warrant a new phase imo since it should only be run once per compilation instance; anything it does can either be done in unpack, or in configure should that be more useful. src_prepare is a logically distinct action (maybe if we called it src_patch it would be clearer?) Er no you're fine, I've been thinking of it as src_patch for quite a while now. Certainly we only want to patch sources once every time we want to build a package; what if patching is expensive? Indeed, that was my point above; it only needs to be done once per instance, whereas configure is something that might well be done more than once. How does that change by having it in unpack (which is empty for a live vcs pull in any case)? Also, if you added support for declarative patches, I think you'd soon end up in a similar situation as with unpack, where there simply isn't a need for the ebuild author to write their own in the vast majority of cases. Thing is you'd then be stuck with a new phase and unable to withdraw it, cos it only took 10 minutes to add. The point being the same argument that is for src_configure (that it is expensive and adding it makes ebuilds clearer) could be said for src_prepare (preparation could be expensive and it makes ebuilds clearer). The compelling argument for configure isn't that it's clearer (although it helps): it's that not having it makes it _impossible_ to restart an ebuild which uses the standard configure make cycle, say if the user has turned off collision-protect in order to get OpenOffice to install, or as recently highlighted in #-dev-help, for an ebuild dev to do the same, via FEATURES=noclean ebuild package.ebuild install. Presumably that's the root cause of confusion over where to put eautoreconf, since putting it in unpack and not compile gets round the issue. So why again should we not add it? I have no issue with the function being part of the EAPI; adding it as a _phase_ seems less wise, but like I said, I accept the consensus is against me.
[gentoo-dev] Re: Re: Re: [RFC] What features should be included in EAPI 2?
Ciaran McCreesh wrote: On Tue, 19 Aug 2008 21:27:03 +0100 Steve Long [EMAIL PROTECTED] wrote: On Tue, 19 Aug 2008 23:31:17 +0530 Arun Raghavan [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: The benefit is that it's a logically separate action, and will avoid all the silliness of people repeatedly changing their minds about which phase should do the eautoreconf calls and so on. Er, that would be the new src_configure? Oh really? Hmm fun as it isn't playing these games with you.. In the grand scheme of things, no. In the grand scheme of things, you only *need* a single src_ function. From a maintainer convenience perspective, however, src_prepare is marginally more useful than having a split src_configure. How so? From a user point of view, and from a maintenance point of view, src_configure is very useful. Any reason you can provide for src_configure being useful can be used with slight modification for src_prepare. Which is no reason to add a new phase. OFC if zac wants to provide it that's entirely up to him. It's a better mapping of the things ebuilds do than the current set of functions. The logic is this: lots of ebuilds end up duplicating src_unpack (or, in future EAPIs, calling 'default') and then adding things to do preparation work. Experience suggests that the most common reason for overriding src_unpack is to do preparation work, not to change how things are unpacked. Yeah I've always seen src_unpack as being more cogent to preparation of src files, than to actually untarring stuff. Yes, the 'unpack' in the name really does go along with the phase being used to prepare things. Oh so this is about correct nomenclature rather than anything else? I see. So what? Why make a new phase which every new dev has to know about, and we have to provide pre_ and post_ hooks for, when the existing phase covers the usage fine? Make a phase for each common logically distinct operation. Which, with src_prepare being added, we almost have. Yes, I see, because it's really needed; real functionality our users have been crying out for. (The one missing is a src_fetch_extra or somesuch, for use by the scm eclasses. But that wants special handling, and is probably best left to another EAPI...) Yes, a defined, configurable API for dealing with any version control would be useful, though your minion seemed to argue against it in #-portage. I can think of a couple of things that would be more useful to end-users: pkg_check for interactive ebuilds (eg license acceptance or media access), proper support for cross-compiling, integration of prefix, better handling of overlays, and of binpkgs.. (Number-wise... For Exherbo, where the split's already been made, custom src_prepare functions are three times more common than custom src_unpack functions. And that figure's significantly lower than what Gentoo would see, because with exheres-0 'default' functions you don't need to write a src_prepare if you're merely applying patches.) Well it's easy enough to auto-apply patches, given a declaration in the ebuild (since files for all versions are in the same dir.) It certainly doesn't need a new phase. Well, if you're proposing that Gentoo also adopts the more complicated default_* functions from exheres-0, you're more than welcome to write up a proposal... Tsk of course not. default functions are in the pipeline in any case, but glad to see you're still using this list for proselytising your pet project while avoiding true discussion. In any event, it wouldn't be needed. The *only* potential benefit I see here is that at some point of time in the nebulous future, it might be possible to tell the PM to always skip src_prepare in order to give a system where everything is vanilla. Such a system wouldn't be usable... Not all of Gentoo's patches are non-essential. So the real, fully-defined, explicit benefit is.. The same as the benefit of splitting src_compile into src_configure and src_compile, except that it'll be of use to a slightly larger proportion of ebuilds. As ever, you fail to argue the actual case, preferring to hide behind the same reasons as.. which is a variant on the if you don't understand some one line comment, you're not qualified to discuss anything (plus you're ugly.) The reasoning others have given (yes it is possible to explain why without making people read thru 20 one line emails) is that this would be useful for live ebuilds. In maintenance terms (when looking at the lifecycle of an ebuild) I don't see the need, since there is no unpacking required from a vcs pull. Once it's made into a normal ebuild, any preparation would necessarily require review and might not be needed at all. Call the function what you like (or add a new phase with the hooks) it's still logically one point in time. For a live ebuild it's to prepare the src, for a normal one to (possibly) unpack
[gentoo-dev] Re: News item: World file handling changes in Portage-2.2
Duncan wrote: every time I try to emerge -NuD system I think there's a good case for system and world without the set specifier working the way they always have. I for one am very aware if I type in @world (ie not system, useful for -e) vs world. I don't see any benefit to the user in jettisoning the existing metaphor. What do others think?
[gentoo-dev] Re: [RFC] What features should be included in EAPI 2?
Ciaran McCreesh wrote:
On Wed, 13 Aug 2008 01:18:33 -0700
Zac Medico [EMAIL PROTECTED] wrote:
* The old src_compile phase function is split into separate
src_configure and src_compile fuctions.
If you're doing new phases... Exheres has been using src_prepare, after
src_unpack, to avoid having lots of things of the form:
src_unpack() {
default
patch blah
eautoreconf
}
Besides saving one line of typing, what is the benefit of adding this new
phase?
[gentoo-dev] Re: Re: News item: World file handling changes in Portage-2.2
Joe Peterson wrote: Duncan wrote: That's an interesting idea. I don't personally care either way, as long as @world continues to /not/ include system/@system, but having world (without the @) continue to include system /would/ be useful for backward compatibility. I think it'd be much better in terms of ease of educating the vast majority of stable users, as the @ is new anyway, so it can have new behaviour without a problem, but having new behaviour for world does present a significant re-education/retraining issue. Yeah that was my thinking (only better expressed ;) The only drawback I see is that we would then have the following: @system == system ...but... @world != world This, I would think, could cause confusion too - and we'd have to live with and document this quirk. I don't see that as major from a user pov; as soon as you see @ you're in set territory, which is for finer-grained control. We already expect users to have the ability to read docs and the like, and this way we're not introducing any surprises; for the standard update procedure we're all used to, sets don't come into it. How about issuing a warning when portage starts if the user specifies world (with no @ sign) as the only specified target *and* @system is not in world_sets? It's starting to get tricky.. ;) It would warn that the world set no longer automatically includes system (i.e., @system) and also that it is better, from now on, to explicitly use the @ sign for all sets like world and system (since these two are special cases grandfathered in). .. and we still get the issue that future usage would mean needing: emerge @world @system # or should it be the other way round? ..when we used to have a simple 'emerge world'[1]. I don't see how that helps our users. iow the change feels like a loss, not an improvement (which the set code certainly is), when a little tweaking with the option parser would mean we had both uses. I see it as polishing the UI, nothing more. Maybe there's a case for dropping system as a special-case over time, and giving a deprecation warning. Personally I don't see the problem with simply continuing to support it, or even changing to mean system without any user-defined stuff/ as per-profile; option parsing is hardly the bottleneck ;) [1] Assuming user doesn't want @world always including @system, which makes sense to a power-user who would be interested in sets, as Duncan showed.
[gentoo-dev] Re: Re: [RFC] What features should be included in EAPI 2?
Ciaran McCreesh wrote: On Tue, 19 Aug 2008 23:31:17 +0530 Arun Raghavan [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: The benefit is that it's a logically separate action, and will avoid all the silliness of people repeatedly changing their minds about which phase should do the eautoreconf calls and so on. Er, that would be the new src_configure? a) Is this really an issue for maintainers? It's not a huge issue, any more than src_configure is. Equally, it's not expensive to implement. b) Does it really matter? In the grand scheme of things, no. In the grand scheme of things, you only *need* a single src_ function. From a maintainer convenience perspective, however, src_prepare is marginally more useful than having a split src_configure. How so? From a user point of view, and from a maintenance point of view, src_configure is very useful. c) So the flow will look like: ... src_unpack src_prepare src_configure src_compile ... To me this seems like an unnecessary overgeneralisation. It's a better mapping of the things ebuilds do than the current set of functions. The logic is this: lots of ebuilds end up duplicating src_unpack (or, in future EAPIs, calling 'default') and then adding things to do preparation work. Experience suggests that the most common reason for overriding src_unpack is to do preparation work, not to change how things are unpacked. Yeah I've always seen src_unpack as being more cogent to preparation of src files, than to actually untarring stuff. So what? Why make a new phase which every new dev has to know about, and we have to provide pre_ and post_ hooks for, when the existing phase covers the usage fine? (Number-wise... For Exherbo, where the split's already been made, custom src_prepare functions are three times more common than custom src_unpack functions. And that figure's significantly lower than what Gentoo would see, because with exheres-0 'default' functions you don't need to write a src_prepare if you're merely applying patches.) Well it's easy enough to auto-apply patches, given a declaration in the ebuild (since files for all versions are in the same dir.) It certainly doesn't need a new phase. The *only* potential benefit I see here is that at some point of time in the nebulous future, it might be possible to tell the PM to always skip src_prepare in order to give a system where everything is vanilla. Such a system wouldn't be usable... Not all of Gentoo's patches are non-essential. So the real, fully-defined, explicit benefit is..
[gentoo-dev] Re: The Plethora of Patches
Andrew D Kirch wrote:
Here's the script that I used to generate this.
Just some bash hints. In a nutshell: please don't use ls in scripts.
I have not manually
reviewed all of thousands of patches to determine the unique situation
of each patch, however I would like a suggestion on how to demonstrate
_real_ statistics short of auditing each and every patch in portage
which I personally don't have time to do.
I think it's a great idea, and the other reply from robbat gives you a great
spec to start from in terms of classification.
for I in `ls`; do
for f in *; do
Globs have a lot to recommend them: see http://wooledge.org:8000/glob
PATCH=`ls -R ${I} | grep patch | wc -l`
DIFF=`ls -R ${I} | grep diff | wc -l`
COUNT=$(( ${PATCH} + ${DIFF} ))
while read -rd ''; do let count++
done (find $dir \( -name '*.diff' -o -name '*.patch' \) -print0)
..in the general case, where you actually need a recursive descend. (We
don't here.)
if ! [ ${COUNT} == 0 ]
then
echo $I $COUNT
fi
((count)) { echo $dir : $count }
See http://bash-hackers.org/wiki/doku.php?id=syntax:words for an explanation
of why the quotes make a difference.
Putting it together you end up with this:
#!/bin/bash
# ./countPatchFiles patchCount
# sed -nr '/^Category: (.*): (.*)/s//\1\2/p' patchCount |sort -n -k 2
PORTDIR=$(portageq envvar PORTDIR)
declare -i count tot=0 cTot
shopt -s nullglob
for d in $PORTDIR/*/; do
c=${d#$PORTDIR/}; c=${c%/}
[[ $c = *-* ]] || continue
cTot=0
echo $c 2
for p in $d*/; do
files=($pfiles/*.patch $pfiles/*.diff)
[EMAIL PROTECTED]
((count)) || continue
p=${p#$d}; echo $c/${p%/} : $count
((tot+=count,cTot+=count))
done
echo Category: $c : $cTot
done
echo Total: $tot
-- HTH,
igli.
(The files are in that array, if their names should be needed.)
[gentoo-dev] Re: [RFC] Shall we create a ballot for PROPERTIES value definition proposals?
Zac Medico wrote: Given the vast number of possible choices to consider when defining new PROPERTIES values [1], perhaps we should create a ballot and hold a vote on definitions that people have submitted. I suppose that voters would be able to vote yes or no on each proposed property definition and they would also be able to write in one or more alternative names for the definition. That makes a lot of sense, although I'm not sure you need to get consensus on which properties should be introduced: if the pm teams all agree a flag is needed, it should be in, imo. Names would be better to throw out for wider consensus, due to the i18n and the fact that pm users will need to type them in.. I don't know what the best method(s) to carry out a vote like this would be. Does anybody have any suggestions? How about a poll in portage programming for each flag under consideration, with options for names being considered? You could add a Some other name which I will suggest in a post option. No this flag is a bad idea should come from the dev ml imo, with the reasons explained and discussed fully.
[gentoo-dev] Re: Retirement
Bo Ørsted Andresen wrote: My retirement is probably long overdue as I haven't really been active for several months. It is now clear to me that Gentoo is not moving in the direction I had wished for and the last council election indicates that most current Gentoo developers appear to be satisfied with this current direction. Therefore farewell. If anybody wants to reach me I can be reached at bo.andresen at zlin.dk. Sorry to see you go. It's a shame if the technical direction is what you mean, since Gentoo can clearly accomodate different approaches to the same problem (it is source-based after all.) One thing: the door isn't nailed shut, even if new ones are opening ;-) Hope to see you back iow.
[gentoo-dev] Re: [RFC] New PROPERTIES=virtual value to identify meta-packages?
Zac Medico wrote:
Ciaran McCreesh wrote:
On Tue, 05 Aug 2008 22:15:11 -0700
Zac Medico [EMAIL PROTECTED] wrote:
Does this seem like a desirable way to represent the virtual
attribute? Any suggestions?
Again, I'm not so sure that this doesn't represent multiple separable
concepts. It seems to imply:
* that the install cost is effectively zero
* that the resolution cost is effectively zero
* that the package does not install any files
* that the package does not use any of the (normal?) ebuild phases, and
so does not require exclusive pkg_* execution or pkg_* system state
preservation.
Can't we just treat them like other ebuilds except for the thing
about dependencies? Perhaps more fine-grained attributes could be
added for additional specificity.
Sounds good. Keep existing keyword working how it is, and add new ones
after.
I'd vote for free-{resolve,install} empty and threadable for the other
concepts.
[gentoo-dev] Re: [RFC] New PROPERTIES=live-sources setting for ebuilds?
Zac Medico wrote: As a substitute for the previously discussed RESTRICT=live value[1], I'd now like you to consider an equivalent PROPERTIES=live-sources setting. By specifying PROPERTIES=live-sources, an ebuild will be able to indicate that it uses src_unpack() to download sources from some type of live repository such as cvs, darcs, git, mercurial, or svn. VCS=cvs|svn.. seems a lot cleaner, expressing simply that the ebuild _can_ download its sources. Whether that's to a specific release, a rolling upgrade, a 'oneshot latest' etc is up to the _user_, expressed via any of the existing mechanisms. A simple map of vcs to eclass (in a config file somewhere, system wide and repo-specific spring to mind) means the manager wouldn't have to change to handle a new version control system, given a sane base API. However, numerous people has expressed a desire to have a new variable to represent a different category of boolean attributes, so as not to pollute the RESTRICT variable with values that don't fit well into existing RESTRICT nomenclature conventions. Seems useful as a way to introduce variables which might later be promoted to more than a simple 'presence=yes'-type, akin to py 'future' Thanks for all your hard work; 2.2 has proven to be worth the wait, and seems to be moving quickly.
[gentoo-dev] Re: Bug wrangling
Diego 'Flameeyes' Pettenò wrote: Donnie Berkholz [EMAIL PROTECTED] writes: Would it be possible to add the tree categories as products and the packages as components thereof? It makes moving a bug from one package to another quite a complex task though, as it requires two confirmation screens... and trust me that happens often enough. Shouldn't that just be scripted via pybugz? A GUI for that would be nice; perhaps as a pida[1] module. Frankly it appals me that y'all have so much time to write bash scriptlets and none to develop tools for your own use. Plus that would work fine if we had a bugzilla for ebuilds only, but would you really mix categories together with Infra, Portage, Gentoo Hosted Projects, ... ? Who cares? It's more organisation than you have now, and as I understand Duncan's suggestion it's first about adding a category above pkgs within Ebuilds foo (though I think he mixed up interface and tables a bit, sorry Duncan ;) Tree is the most fundamental work, besides portage. I guess a tag cloud would be nice tho. No reason you can't build associated metadata webapps on another host (cf beandog's portage postgres db[2].) [1] http://pida.co.uk/ [2] http://packages.larrythecow.org/ there's a FF plugin at: http://mycroft.mozdev.org/download.html?name=larrythecow -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [RFC] global useflags
server -- never did get a rational explanation of what it breaks. and now USE defaults work there's simply no excuse imo. I note openldap in 2008.0 profile uses minimal which has *always* been acknowledged as the wrong way to build a client installation, despite its long-standing use in mysql. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Bug wrangling
Diego 'Flameeyes' Pettenò wrote: Steve Long [EMAIL PROTECTED] writes: It makes moving a bug from one package to another quite a complex task though, as it requires two confirmation screens... and trust me that happens often enough. Shouldn't that just be scripted via pybugz? A GUI for that would be nice; perhaps as a pida[1] module. Frankly it appals me that y'all have so much time to write bash scriptlets and none to develop tools for your own use. I like Bugzilla for the very reason I can look, comment and in general manage bugs with decency without needing client software beside a webbrowser, and I'm rarely without a webbrowser, heck, I had one at hand even while I was hospitalised (not in the ICU though, that was boring). Anything that requires me an extra software is something that I'm more likely _not_ going to use. OK so you'd like a webapp version as well. [EMAIL PROTECTED]: Users regularly offer help in this kind of area, simply because they use the same interfaces as the devs, only for it to fall at the second or third dev they interact with, if they're lucky. ] Plus that would work fine if we had a bugzilla for ebuilds only, but would you really mix categories together with Infra, Portage, Gentoo Hosted Projects, ... ? Who cares? Uh, I do, as I tend to report a lot of bugs and I don't want to have to use the find command of my browser to see where the heck should I report it. Don't even get me started on template bugs that I use to mass-report problems. And probably most users would find the huge and long product list to choose from most likely confusing. Users can't get it right already with the short list we have, reporting bugs on Bugzilla product which have nothing to do with Bugzilla... Yeah but the point of hierarchy is so that you do one step at a time (if you want) via category - package or just file the way you're used to. We're still only talking about a small part, in data structural terms, of bugzilla's schema, however much storage is allocated to the base level bugs. Keeping existing workflow would seem to be a requirement. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Bug wrangling
Mark Loeser wrote: Making an actual bug wrangling team (subproject of QA) is something I've been toying around with in my head. I'd love to get an actual team set up so we can encourage users to help us get the information we need in bugs so it is less work for us. Several other distributions have such projects, so we have something we can use as a template. I brought this up last year[1][2] wrt WINE triage. GNOME has a similar thing ofc, so Gentoo devs are used to working with this model. Irrespective, it doesn't preclude the need for a good bugmaster[3] but should be seen as complementary to that person (it's rarely more than one apparently) iow to support that person in their work. That requires non-technical things (*cough* follow-up) like a sense of teamwork, and not looking down on people who don't have cvs commit access. Of course those also make it more likely that people will want to volunteer for triage, or indeed anything else (which can be a virtuous circle.) I'd moot Patrick as a useful bod because he can automate much of this. [1] http://article.gmane.org/gmane.linux.gentoo.devel/46855 [2] http://article.gmane.org/gmane.linux.gentoo.devel/49546 [3] http://tieguy.org/talks/LCA-2005-paper-html/index.html -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: RFC: qemu - add gcc-3.x dependency
Matthias Schwarzott wrote:
Well, you want it compact, without loops.
Here is it:
set -- /usr/bin/gcc-3*
Get first entry: CC=$1
Get last entry: eval CC=\${$#}
Nice one, yeah I thought : splitting was posix silly me ;)
I still shy clear of eval for general use and you have to go thru
contortions with sh, so I'll stick with BASH arrays and syntactic sugar
which gets twisted enough as it is.
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: qemu - add gcc-3.x dependency
Matthias Schwarzott wrote:
Code may look like this:
# get last one of sorted list
for t in $(ls -1 /usr/bin/gcc-3*|sort); do
use teh globs, luke ;)
for t in /usr/bin/gcc-3*; do # will already do this, sorting according to
LC_COLLATE order (set to C or POSIX [same thing] for ebuild.) There's no
need to step through every one either:
t=(/usr/bin/gcc-3*); [EMAIL PROTECTED]: -1}; unset t # get rid of array storage
(using same var for both, eg [EMAIL PROTECTED]: -1} only sets the first cell;
the
rest of the array is still live. var is a synonym for var[0] in BASH.)
set -- *
t=${@: -1} # works here as well but dunno if that applies to all sh (the -1
expansion, not the set.) In any event not needed in BASH since arrays make
our life so much easier ;)
cf: /msg greybot ls and http://wooledge.org/mywiki/glob -- remember you can
do, eg: for i in portage/*/*foo*/*.ebuild
or a more common example: for f in */*/.jpg
It's not find, but it is efficient and filename-safe.
Regards,
steveL.
(Please, no complaints about not using spaces in filenames, there's no
telling where your script could be used-- if it's written correctly.
Subshells and externals as well; why fork and waste resources we don't have
to?)
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: preserving mtimes
Zac Medico wrote: It's currently possible for ebuilds to call the insopts, diropts, exeopts, and libopts functions to modify these variables. If they add the -p option, then timestamps will be preserved. I suppose we can add -p to the default options if that's what everybody wants. Gets my vote (or new-fangled backport from pkgcore if it's more efficient.) -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: On Sat, 19 Apr 2008 18:38:06 +0200 Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote: I don't know what the general use of pkg_preinst is, but in pkg_postinst the package itself should be runnable, so its RDEPENDS should be installed and usable at this point. So perhaps we should define that usable means each of its RDEPENDs is installed and has had its pkg_postinst function run. The recursion of that definition then comes from the requirement that RDEPENDs should be usable before pkg_postinst starts running. No good. That prevents RDEPEND - RDEPEND cycles from being solved, and the package manager has to be able to solve that. Use PDEPEND. SRC_UNPACK_DEP=app-arch/unzip SRC_COMPILE_DEP=dev-scheme/bigloo SRC_INSTALL_DEP= Labels are a cleaner solution to this. But again, we're discussing current EAPIs here. While I like labels they need to be discussed more on-list as well as on bugzilla (it's not reasonable for you simply to advertise them and then close down discussion.) For instance, there is no reason everything has to be loaded into just one extant metadatum, not do they preclude new metadata (such as a SRC_DEP here.) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] DevRel policy update
Petteri Räty wrote: Wulf C. Krueger kirjoitti: How to gain power the easy way and obsolete conflict resolution in just one commit: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.18r2=1.19 Please use the appropriate mailing list. Nothing technical here. This thread belongs to -project. Indeed. I agree it simply clarifies the existing policy, in that devrel lead or infra previously had a call on whether an issue were critical. It'll still be transparent and a lead who used that power lightly would soon get relieved of duty one would hope. (If not kick up a stink then, not now, as nothing's really changed.) -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: New developer : Chris Henhawke (bunder)
Denis Dupeyron wrote: Please everybody, give a very warm welcome to bunder. Yay bunder! Well done, man. :-) -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote:
On Sun, 27 Apr 2008 10:41:57 +0100
Steve Long [EMAIL PROTECTED] wrote:
Use PDEPEND.
PDEPEND has a different meaning, and isn't suitable for runtime
dependencies.
PDEPEND should be avoided in favour of RDEPEND except where this will
create circular dependency chains.[1]
Sounds very much like it is used for runtime deps, and breaking RDEPEND
cycles has often been given as its purpose in #-portage and #-dev-help, as
well as in the devmanual.
While I like labels they need to be discussed more on-list as well as
on bugzilla (it's not reasonable for you simply to advertise them and
then close down discussion.) For instance, there is no reason
everything has to be loaded into just one extant metadatum, not do
they preclude new metadata (such as a SRC_DEP here.)
Labels can be discussed on-list whenever there's a chance in hell of
Portage implementing any non-trivial new features.
That's not exactly in the spirit of collaboration (nor are your continuous
snipes at portage.) New features should be discussed with a wider audience
than bugzilla, not just used to advertise one impl and slipped in via an
overlay. Further, having a consensus would allow pkgcore to move ahead with
a more solid spec, and that /is/ conducive to quicker implementation in
portage, since those two teams do know how to collaborate effectively.
Anyway, I'm going with the second wording in the original email.
snip more insults
Of everything suggested, only
the two original wordings are correct, and of those two, the second is
better defined.
2b) seemed better. With use of PDEPEND in the manner outlined, it simply
means pkg_{pre,post}inst can't rely on the PDEPEND'ed pkgs, only those in
RDEPEND.
Build-time dependencies wouldn't appear to cover the use-cases brought up,
nor are they relevant for binary installs. I can see how it would be easier
for the PM to be able to go for one or the other, but it doesn't give an
ebuild author a consistent base. The intersection does but doesn't allow a
package to call itself (one of the use case brought up.) PDEPENDs are used
at ebuild authors' discretion aiui, and in collaboration between the two
maintainers: that judgement would seem to be useful to decide which
interdependent package can call the other, which is very much dependent on
the context. (A classic case of something that can't be solved
automatically.)
[1] http://devmanual.gentoo.org/general-concepts/dependencies/index.html
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: Re: Re: New global USE flag: keyring
Jeroen Roovers wrote: On Mon, 21 Apr 2008 15:02:29 +0100 Steve Long [EMAIL PROTECTED] wrote: Sorry to get technical but how difficult is it really to change USE flag names? I appreciate that users are out of sync yadda yadda, but could this kind of thing not be considered out of band data similar to news? I accept that portage has to maintain compatibility but aiui the old way of doing this was simply depending on a version of portage that had the capability. Since we're only talking about ~10 packages, is that so much of a hardship? After all, I'm sure the other manglers don't lag behind emerge, based on the hyperbole. Do they? I'm deeply sorry. I read all of that three times and while it seemed to make sense the first time, by the third time I saw the error of my ways. You've lost me; if I've caused you offence somehow please accept my apology and mail me off-list to tell me how. Regards, Steve. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: Re: New global USE flag: keyring
Jeroen Roovers wrote: On Sun, 20 Apr 2008 18:06:07 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: I'd say we should convert it to a global use flag now with a good description and change it to gnome-keyring later in case we really have a package which needs 'keyring' for something else. Needless to say it would save quite a few users from needlessly rebuilding a few packages. That's green thinking. :) Sorry to get technical but how difficult is it really to change USE flag names? I appreciate that users are out of sync yadda yadda, but could this kind of thing not be considered out of band data similar to news? I accept that portage has to maintain compatibility but aiui the old way of doing this was simply depending on a version of portage that had the capability. Since we're only talking about ~10 packages, is that so much of a hardship? After all, I'm sure the other manglers don't lag behind emerge, based on the hyperbole. Do they? -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: escaping variables in sed expressions
Ciaran McCreesh wrote: Nor do most Unix apps, since they tend to be written in C using all those C library functions that work on null terminated strings. Null introduces far more problems than it solves, character-wise... ..but it's fine as a terminator, if you know what you're doing. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: Re: RFC: New build types
Petteri Räty wrote: Steve Long kirjoitti: I don't see how it would wreak more havoc than a novice using, eg ANT from Java which s/he is comfortable with, and then further having to learn BASH peculiarities when things don't fit with the eclass. But yeah, the fun is what attracts me to the idea more than anything. Java needs to be compiled and ant is meant to be started from the command line. Of course you can invoke the main method from Java but what's the point? Developers have to be able to review ebuilds and having all those different languages would make the job harder and I don't really see benefits. If you need something bit more complex done in an ebuild, you can always use something like inline python. Yeah, sorry I haven't used Java seriously since 1.1 (apart from some MIDP stuff) so haven't used ANT. I'm thinking more in terms of how Java was touted as network code, similar to tcl (which is one scripted setup I would be interested in.) So where you have a VM already instantiated, along with whatever SecurityManager and so on, you have a framework for user, shared or system installs, according to privilege level, with dependency resolution handled by the package manager. (The dependencies don't have to be confined to what the language knows about.) You're right though, that's not of so much interest for stuff where you already have ebuilds with associated shell infra, which you're used to maintaining. Thanks, igli. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: Re: RFC: New build types
Brian Harring wrote:
On Thu, Mar 20, 2008 at 06:51:13AM +, Steve Long wrote:
I don't have figures, but my understanding is that one of the major
factors in pkgcore's speed (which *is* impressive, even if the UI isn't
quite there yet) is that it doesn't reload bash for every phase. (The
whole ebuild daemon or ebd thing.)
From a speed standpoint, EBD is only relevant if we're talking about
metadata regeneration-
http://gentooexperimental.org/~ferringb/blog/archives/2005-03.html#e2005-03-05T16_59_39.txt
Ah OK; thanks, very interesting post.
Generally speaking, if you're sourcing to get metadata (regardless of
the underlying format), you're already screwed- cache exists for a
reason and is massively faster to rely on. Pkgcore's speed comes
about from careful design + a massive amount of JIT, EBD is faster
then the alternatives but that's *only* relevant for metadata
regeneration.
Would the metadata regen be quicker if the relevant file were in python
rather than bash?
Finally, bear in mind we're talking about build phase here- even if
the pkg is just a straight unpack/copy, the bottleneck there isn't
going to be the bash bits for setting up the env, it's going to be the
unpack, copy, multiple QA checks that do repeated find's across ${D},
multiple file invocations for same file, etc. Seriously- profile a
merge sometime, even on non-compilations the large time slices are
never bash.
Understood; thanks for discussing.
I was under the impression that implicit in the design of portage/pkgcore,
was that build scripts wouldn't necessarily be in bash, and that ebuild was
simply the bash format. Other formats in scripting languages seemed a
no-brainer; sorry if it was off-base.
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: RFC: New build types
Rémi Cardona wrote: Steve Long a écrit : First and foremost to give an environment wherein people can write their installation scripts using the language they are most comfortable with. If bash is not easy or straightforward enough for what you are trying to achieve, then I'd say the package is broken (ie, hand-made configure script, odd makefiles and whatnot). Better fix the package rather than rewriting ebuilds, make the world a better place. Heh, I'm fine with BASH believe it or not ;p nor do I have that much interest in the other scripting languages. I really just think it would make porting stuff to Gentoo a lot simpler for people who don't know Cbut do know their language of choice. Secondly efficiency; in the case of a pbuild it could be run from within the PM; for something like a jbuild it would use the native tools and existing libraries like ANT. For hbuild it would tie into Cabal. While these may be used already, we go from PM - BASH - LangX. I'm just saying give the _option_ to leave out the BASH bit when you have mature tools in langX. Care to back that up with any sort of figure or number? Is bash really the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash. But then again, I don't have any numbers to back that up either... I don't have figures, but my understanding is that one of the major factors in pkgcore's speed (which *is* impressive, even if the UI isn't quite there yet) is that it doesn't reload bash for every phase. (The whole ebuild daemon or ebd thing.) Honestly, maybe it could be a fun project, but I'm hardly convinced it would bring any sort of real advantage to the tree. In fact, having ebuilds in many languages would probably wreak havoc more than anything else. I don't see how it would wreak more havoc than a novice using, eg ANT from Java which s/he is comfortable with, and then further having to learn BASH peculiarities when things don't fit with the eclass. But yeah, the fun is what attracts me to the idea more than anything. It's something I'd imagine would be used only for packages developed in the relevant overlay, since that's where the people who know the language develop stuff (and they'd be the ones maintaining their version.) However, they'd need to know that, once they've signed off on it, the central tree will support it without further code changes. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [RFC] Major changes to the Gnome2 Eclasses
Rémi Cardona wrote:
Now, basically, if the portage metadata or QA people could tell me a way
to figure *all* the ebuilds that inherit gnome2 *and* have a
pkg_preinst() function somewhere (either in the ebuild or in an eclass
somewhere) I'd really appreciate it, as I really don't want to read
through thousands of ebuilds to figure it out.
PORTDIR=$(portageq envvar PORTDIR)
# Get eclasses which export pkg_preinst()
preEclass=($(qgrep -EeCl 'EXPORT_FUNCTIONS.*pkg_preinst'))
# We don't want the eclass/ prefix
preEclass=([EMAIL PROTECTED]/#eclass\/})
# or the .eclass suffix
preEclass=([EMAIL PROTECTED]/%.eclass})
# make a regex for an ebuild with a pkg_preinst, or inheriting one
# of the eclasses
IFS='|'
search=^[[:space:]]*(pkg_preinst\(\)|inherit .*(${preEclass[*]}))
unset IFS
# find matching ebuilds
while read ebuild; do grep -El $search $PORTDIR/$ebuild
done (qgrep -Cel 'inherit .*gnome2')
# just the packages (would need to count dirs in PORTDIR and amend awk
# accordingly to use the env var)
while read ebuild; do grep -El $search /usr/portage/$ebuild
done (qgrep -Cel 'inherit .*gnome2') | \
awk -F/ '!s[$4/$5]++ { print $4/$5 }'
If you wanted to do something with the files, you'd use:
grep -Eq $search $PORTDIR/$ebuild files+=($PORTDIR/$ebuild)
in the loop, and then access the [EMAIL PROTECTED] array after. You can't do
that with a pipe, see http://wooledge.org/mywiki/BashFAQ/024
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: New build types
Rémi Cardona wrote: What would be the point of such a change? What problem are you trying to solve or to improve? First and foremost to give an environment wherein people can write their installation scripts using the language they are most comfortable with. Secondly efficiency; in the case of a pbuild it could be run from within the PM; for something like a jbuild it would use the native tools and existing libraries like ANT. For hbuild it would tie into Cabal. While these may be used already, we go from PM - BASH - LangX. I'm just saying give the _option_ to leave out the BASH bit when you have mature tools in langX. You'll need to answer those questions anyway should you ever need to write a GLEP for that. Yeah, that's a long way off; no point doing a GLEP without a working implementation to show what you mean, imo. No point dedicating coder resource to implement if it'd never get used in any case. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: New build types
Luca Barbato wrote: Steve Long wrote: Something that's been discussed on IRC is the idea of a .pbuild file, written in Python. I can also think of .cbuild (C) .Cbuild (C++) .sbuild (Scheme) .hbuild (Haskell) and .jbuild (guess;) as being of immediate use, (although I accept I might be the only one interested in the first ;) I do not see any improvement per se. Well I agree C and C++ aren't very useful, since they are more than adequately covered by make et al. With the others, there are setup tools like distutils in the language already. How do others feel about such an addition? I think it's pointless. Fair enough. It's intended to make it easier to write install scripts. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] RFC: New build types
Something that's been discussed on IRC is the idea of a .pbuild file, written in Python. I can also think of .cbuild (C) .Cbuild (C++) .sbuild (Scheme) .hbuild (Haskell) and .jbuild (guess;) as being of immediate use, (although I accept I might be the only one interested in the first ;) The basic idea would be to replace ebuild.sh with an API equivalent (where API is defined as stable portage or an approved PMS which adequately covers this aspect.) How, or indeed whether or not, helper utilities equivalent to eclasses (or an elib) would be provided, would of course be down to whoever wrote and maintained the relevant code. How do others feel about such an addition? -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: New developer: Bo Ørsted Andresen (zlin)
Iain Buchanan wrote: On Thu, 2008-02-28 at 14:28 +0200, Petteri Räty wrote: He has been breaking the tree for a while now but as Calchan has been having availability problems I get to insult him a little bit later than usual. Bo hails from Aalborg, Denmark. He studies to become a control engineer. On the Gentoo side he is one of the people who enabled KDE4 coming to our main tree via contributing to their overlays. He has also contributed to Paludis. Let the usual mud slinging begin. Regards, Petteri zlin: I can't officially welcome you as I'm not on the inside, so good evening ;) ++ another unoffical congradulashuns, to someone who freely shares knowledge. Wish i had an insult I could sling *sheesh* ;p -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Keyword amd64 - x86_64
Fabian Groffen wrote: Ben de Groot wrote: Bernd Steinhauser wrote: | Wouldn't it be more clean if it is amd64 just like the Linux one? | Because the arch basically is the same. I think that | amd64(-linux) -- x86_64-fbsd | x86(-linux) -- x86-fbsd | | would be more confusing than | amd64(-linux) -- amd64-fbsd | x86(-linux) -- x86-fbsd I agree, and vote for consistency as well. Yes, but as mentioned before, my problem is that amd64-macos really doesn't make any sense to me. I accept that it seems odd, but EM64T is a clone of amd64 in the same way that amd32 is a clone of x86. If we're consistent across the board, it leads to less confusion, once a user knows they're on amd64 (I'm thinking of support questions more than anything.) Whatever you decide to call it for macos/prefix, I'd vote against x86_64-fbsd and for amd64-fbsd, since renaming amd64 is not going to happen afaict. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: The future of ebuild
Felipe Contreras wrote: On Sat, Feb 23, 2008 at 10:45 PM, Alec Warner [EMAIL PROTECTED] wrote: On 2/20/08, Felipe Contreras [EMAIL PROTECTED] wrote: b) Error are difficult to handle since bash doesn't have exceptions I disagree here: most errors are fatal anyway any non fatal errors can be printed and saved via the elog facility. Yes, for the most common usage that's true, but that think about this example: I'm compiling gstreamer-plugins-good, which needs libraw1394, but the compilation fails, perhaps that user is not interested in that particular plugin so a dialog can pop up and the user can choose if to continue without the libraw stuff or fail. That would typically be configured via USE flags, or for some things via a USE expand, like CAMERAS for gphoto. I agree there is scope for UI work, but I think that's better done by other apps calling the package manager, in the same way as other distros do. For Gentoo, we use update from the CLI, and himerge for a GUI, although portato (GTK) and kuroo (KDE) are both nice too. Typically in such an instance a user would see the package fail, and try with a different USE setting. We're adding USE editing to update, should be done this week; for all the GUIs that's already possible. In terms of what you're discussing, the package manager has to be able to run without user interaction, but a next generation build system is possible (eg pbuilds in python have been discussed on IRC, and qmake et al are around); ebuild is more a meta-format in that it can use a wide variety of base tools. update: http://forums.gentoo.org/viewtopic-t-546828.html http://www.haskell.org/himerge/ http://portato.origo.ethz.ch/ http://kuroo.org/ I'm sure that can be done without exceptions but as the complexity increases properly checking/passing around error values/messages becomes tedious. c) Persistent information is difficult to achieve (no database stuff) How is this a bash limitation? Most languages don't have 'database stuff' built in. I don't see how saving stuff to files is much different than the env dumping we do in bash? I guess it's mostly the burden of serializing/parsing all that stuff. Saving to flat files or databases gives the same persistence, and in any case the ebuilds don't mess around with them, the package manager does. It's perfectly possible to use a database to store the information ofc, but at some point you have to deal with the fact that ebuilds are text files edited by humans. A more featured language could allow for example: filtered output, exception handling-state storage-resuming. Portage does all those at the moment (filtering output can easily be done by script, see update, or in an app like kuroo.) But the big deal is with the package definition, recently I learned about Domain Specific Languages, and I think that is the best option. A new dsl allows many interesting features in the package definition itself like: inheritance, exceptions, arrays, hash tables, objects, modules, documentation, information messages, etc. Note that most languages allow for the same things...so why would we author our own language? What runtime would it use? The language can be something very simple that has bash embedded. That has the advantage that you can just copy paste what you are doing already. If it's got bash embedded it won't be simple ;) I see ebuilds as already providing that DSL, in that you have full BASH capability and a library of API functions you can use. I've tried different build systems: rpm, dpkg, autopackage. Unfortunately I never tried ebuild because it was based on bash as far as I could tell. Typically a 'build system' would refer to 'autotools' or 'ant' or 'setuptools' not an ebuild. Is there such a big difference? I'm sure it's possible to by-pass autotools and write down all the commands required to build something in an ebuild. Similarly it's possible to use autotools to compile and install a bunch of packages. You seem to be missing that ebuild is a support metastructure on top of build systems like make, autotools or distutils? Those build systems also need to be updated, but that's another story. What for? After almost a decade of using Linux I still haven't found a build system that suits all my needs. AFAIK ebuild is the most advanced but it's still relying on ancient technology (bash scripts) so there will always be limitations despite the brilliant ideas. Bash is not 'ancient' and it works suprisingly well for the vast majority of cases. I realize using a high level language would probably make some tasks easier (mmm dicts and real arrays). There is the matter of porting over 1 ebuilds however ;) Yeah, bash is pretty good for many things, just doesn't scale that much. I'm not sure where and how it needs to scale. The API provided is very easy to work with and encompasses an
