Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Beyond that, there is the shebang issue which can be addresses via a | combination of automated scans/fixes, and fixing bugs as it's hit. | Hardcoded vars in scripts for the path to a binary are an issue also, | although again, scans can be done to at least check for it. This one's a far bigger issue than might be initially obvious. It would involve rewriting a whole load of autotools innards... Clarify. My knowledge of autotool innards is that it relies on $PATH for lookup of the tools it uses. | Leaves mangling the build process so that the build framework of the | package uses the prefix offset files, rather then / . For c/c++ | source, usual trick from fink afaik involves a mangling of cflags | with -I tacked in. Kinda ugly, although I'd expect there is a better | route. Again, autoconf tinkering. Statement above is from digging through generated configure script. ~harring pgp3yrxiLkcfh.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 12:38:35AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 18:22:37 -0500 Brian Harring [EMAIL PROTECTED] wrote: | On Thu, Oct 06, 2005 at 12:14:30AM +0100, Ciaran McCreesh wrote: | On Wed, 5 Oct 2005 18:00:12 -0500 Brian Harring | [EMAIL PROTECTED] | wrote: | | Beyond that, there is the shebang issue which can be addresses | | via a combination of automated scans/fixes, and fixing bugs as | | it's hit. Hardcoded vars in scripts for the path to a binary are | | an issue also, although again, scans can be done to at least | | check for it. | | This one's a far bigger issue than might be initially obvious. It | would involve rewriting a whole load of autotools innards... | | Clarify. My knowledge of autotool innards is that it relies on $PATH | for lookup of the tools it uses. It does in some places, it doesn't in others. It especially doesn't for things that aren't normally found via PATH. It's a hell of a mess. Examples? ~harring pgpqc9GgtRZ5U.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 01:13:53AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED] wrote: | It does in some places, it doesn't in others. It especially doesn't | for things that aren't normally found via PATH. It's a hell of a | mess. | | Examples? Of stuff in PATH? /bin/sh is assumed throughout to be a Bourne compatible shell (and SHELL and CONFIG_SHELL aren't universally honoured). uname, hostname and sed are called with hard paths (with various fallbacks) in several early on stages. Of stuff not in path? There's no standard and widely used way of digging up where libexec tools are. What's being raised here is issues with making ebuilds handle prefix _perfectly_. Where are the portage issues, so that people can actually jump in and start testing out actual solutions, rather then conjecturing about what may or may not break? ~harring pgpvDKijE0RXh.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 02:23:47AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 20:17:40 -0500 Brian Harring [EMAIL PROTECTED] wrote: | The issue is that you need to fix autoconf before you can claim that | any non-trivial test case works correctly. | | And how are you going to verify autoconf works perfectly without | testing it? Can't. Dead easy to verify that it will break without testing it, though. Just look at the source. Break is a bit heavy, considering autoconf's usage of /bin/sh is pretty limited in terms of syntax. Looking at the source, it'll revert to / for certain bins. A forced autoreconf with a patched autoconf/autotools is required, but again, doesn't do jack with out testing. | The point I'm making is that the only thing required of *portage*, is | the prefix var being used internally, and handed down to the ebuilds. | | Ironing out the ebuild cruft is left to those who want it. Again, | where is the hold up for *portage*? That's rather short-sighted... Portage is irrelevant without the ebuilds. And ebuilds are irrelevant without portage. Point? My point experimentation can start for addressing the issues you keep pointing at still stands. | What's the problem? Why the 101 holes before they even can attempt | it? If you're after shooting the idea down (as I suspect), state so | rather then death by a thousand cuts. Saves us time, really. | | Hell, haubi's patch already lays the ground work for testing it. I'm | not seeing why you're being negative about people even working on it. Because a botched solution is worse than no solution at all. You've seen the mess we end up with when people start working with a half-arsed initial setup. Well plan the sucker out then, as you advocated, or sit back and let them jump in and start working it out. Perhaps they'll decide it's completely unworkable (I doubt it, considering the fact fink's crappy handling of building has made it this far), or perhaps they'll get it working and you won't have as many holes to point at. Regardless, it's their time to spend working on it. Either chip in, or offer _constructive_ advice, or plain step back and let them try to get it working. Note the constructive. Stating it won't work and pulling a new reason why isn't constructive, pointing out each issue as you see it so they can address it (if it's an issue) is a bit more constructive. ~harring pgpLpvBGoQzGq.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 02:40:58AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 20:32:20 -0500 Brian Harring [EMAIL PROTECTED] Portage is considerably less work than the tree. Saving as much effort as possible from an ebuild perspective should be a major consideration, even if it makes the portage side more complicated. Think of how all the ebuild-related problems are going to be solved first. Don't leave it as an afterthought. Round and round we go. The ebuild related problems aren't going to be solved in portage till someone has a general solution that can be pushed into portage/ebuild.sh base template. That's something that requires people diving in and screwing with it. | My point experimentation can start for addressing the issues you keep | pointing at still stands. The sensible place to start experimenting is by adapting existing ebuilds and tinkering with ebuild.sh, not by adding something which may or may not end up being relevant to portage proper. Bluntly, what the hell do you think we're talking about here? In case you haven't caught on, there *are* portage modifications that have to go with it, meaning more then ebuild.sh. Regardless, I'll backport haubi's patch to stable if anyone is after screwing with it, unless michael's has a version that applies cleanly to .53_rc4. Enough dancing, would rather hand it off to those who are interested, and see what they come up with rather then fencing via email (and accomplishing nothing). Michael, got anything I can mold to .5*, or just backport the 2.1 mod? ~harring pgpmLvkkFehel.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 03:01:12AM +0100, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 20:48:26 -0500 Brian Harring [EMAIL PROTECTED] wrote: | The sensible place to start experimenting is by adapting existing | ebuilds and tinkering with ebuild.sh, not by adding something which | may or may not end up being relevant to portage proper. | | Bluntly, what the hell do you think we're talking about here? In | case you haven't caught on, there *are* portage modifications that | have to go with it, meaning more then ebuild.sh. snip lots of you're doing something I think is dumb/I don't agree/slams at pvdabeel/lv/others who have attempted things in the tree Clarification of two things. First- this is external, including the patch. So comparing it to attempts that were done in a live tree is a bit of intentional bullshit/rhetoric. The entire intention of this is to work it out, *outside* of the tree, something those involved know. You seem to be out of the loop, not surprising considering your attitude towards this whole attempt. Second- Not having a clue about what the full set of modifications are going to be until you solve the ebuild side of it is *exactly* why people have to jump in and actually test the damn thing. You can solve as much of it up front as you know will be an issue, testing will reveal the additional issues. Under your suggested route, nothing is accomplished (potentially the reason you're suggesting all issues up front be addressed regardless of whether or not if they'll actually _be_ issues). What you're offering as a proposed/sane route is a route that produces nothing due to the fact you think everything must be solved up front, regardless if it turns out to be an issue or not (let alone identifying everything that may or may not be an issue) . Get the basic portage support up, they iron out the base mods initially needed, and jump in and identify the bugs that crop up further. Essentially, lets see how well this actually works out, rather then listening to you run your mouth about how it's a bad idea whenever it comes up, and all of these things will be issues (/bin/sh usage isn't an issue for the initial test target of osx). Either way, they're doing the work, you aren't, and you really don't have *any* say over their efforts until they finalize a solution and bring it to *devs* (not just you) for merging into mainline. So bluntly, shut up and let those who you think are being retarded, be retarded. Discussions on this list regarding those attempts shouldn't be heckled unless you're contributing to those efforts (and I truly mean *contributing*, not trying to punch holes in embryonic efforts that are trying to get off the ground addressing the major issues up front). Regardless, your points (repeatedly restated in the varying forms) have been noted, and those who are interested have no reason to not move forward with ironing out an implementation, and testing it. I suggest you sit quietly and let them do their work, rather then riding their asses. You might be surprised at what they come up with. If/When they push for inclusion, the merits of their efforts their solution (and outstanding issues) will be evaluated then. Back off and let them do their work, it's not affecting you in anyway, so again, you really don't have any say in it till they push for mainline. So... yeah. I'll post the prefix support backport patch once it's done, few days I'd expect since there is a fair amount of autotooling to deal with also. Those interested, I suggest you chip in, whether to spite ciaran (good or bad reasons, doesn't matter, result does :), or to get this feature you want realized. ~harring pgpadtl900v4S.pgp Description: PGP signature
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Thu, Oct 06, 2005 at 02:14:32PM +1000, Finn Thain wrote:
On Wed, 5 Oct 2005, Kito wrote:
[snip]
My first question would be how to identify ebuilds that respect ${prefix}?
A separate profile/keyword seems wrong.
ICANINSTALLTO was the best idea presented, but that implies it would be
a list of known working prefixes, which seems unrealistic.
What problem was ICANINSTALLTO intended to solve? IIRC, it was discussed
on -dev in the context of vim plug-ins. Apart from vim plugins, has anyone
found other problem packages?
I'm wondering, would a constraint to the effect that certain deps of pkg
foo must be on the same prefix as foo suffice for the vim plugin case?
Or maybe that would work better if expressed, pkg blah can not satisfy a
dep from any pkg on a different prefix. Such constraints would be
possible to implement with a new file in the profile (say, package.local).
That gets into more of ciaran's HOME installation target feature.
Current form for global prefix offset is
DOMAIN=root offset , with offset == prefix offset.
If an ebuild doesn't have DOMAIN=offset, and you're doing a prefix
offset, it's unusable. No question of can I use a dep from another
prefix, with prefix offset you're doing the deps full in an offset.
As stated earlier in this mess of a thread, HOME crap is being left to
those who want it, it'll be implemented by those who want it after
global prefix is ironed out (if it is accepted also).
~harring
pgpEHAG0zrtZw.pgp
Description: PGP signature
[gentoo-portage-dev] [PATCH] bug 107770 ebuild screwing up A when executing phase by phase
Quicky description of the bug is that A was being defined to '' in the
ebuild env; due to the fact ebuild.sh automatically stomps the current
passed in env with the previous env (it's bad, we know it already :),
this resulted in A getting auto set to a bad value, and the value
lingering.
Attached is a patch that fixes this particular issue. Old bug from
the looks of it also, since that declare's been there for quite some
time.
Already in svn also, posting for those interested, and those affected.
~harring
Index: bin/ebuild.sh
===
--- bin/ebuild.sh (revision 2082)
+++ bin/ebuild.sh (working copy)
@@ -1733,8 +1733,10 @@
unset E_IUSE E_DEPEND E_RDEPEND E_CDEPEND E_PDEPEND
-declare -r T P PN PV PVR PR A D EBUILD EMERGE_FROM O PPID FILESDIR
-declare -r PORTAGE_TMPDIR
+for x in T P PN PV PVR PR A D EBUILD EMERGE_FROM O PPID FILESDIR
PORTAGE_TMPDIR; do
+ [[ ${!x-UNSET_VAR} != UNSET_VAR ]] declare -r ${!x}
+done
+unset x
# Turn of extended glob matching so that g++ doesn't get incorrectly matched.
shopt -u extglob
pgpLkmFz6MzPi.pgp
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] bug 107770 ebuild screwing up A when executing phase by phase
On Tue, Oct 04, 2005 at 09:17:22AM -0500, Brian Harring wrote:
Responding to myself, because I'm an idiot, attached is the correct
patch.
~harring
Index: bin/ebuild.sh
===
--- bin/ebuild.sh (revision 2082)
+++ bin/ebuild.sh (working copy)
@@ -1733,8 +1733,10 @@
unset E_IUSE E_DEPEND E_RDEPEND E_CDEPEND E_PDEPEND
-declare -r T P PN PV PVR PR A D EBUILD EMERGE_FROM O PPID FILESDIR
-declare -r PORTAGE_TMPDIR
+for x in T P PN PV PVR PR A D EBUILD EMERGE_FROM O PPID FILESDIR
PORTAGE_TMPDIR; do
+ [[ ${!x-UNSET_VAR} != UNSET_VAR ]] declare -r ${x}
+done
+unset x
# Turn of extended glob matching so that g++ doesn't get incorrectly matched.
shopt -u extglob
pgpRqUu2IkbBe.pgp
Description: PGP signature
Re: [gentoo-dev] lights on internals
On Sun, Oct 02, 2005 at 11:07:13PM +0200, Francesco R wrote:
The ready to cut ebuild at the bottom print it's environment (variable
and functions) to a bunch of files into /var/tmp/fakebuild/.
May be useful for who want to have a look at what and when is
avaible during the various emerge phases (but not limited to).
print_env() {
local fakebuild_output_dir=/var/tmp/fakebuild
mkdir -p ${fakebuild_output_dir} || die
[[ -z ${fakebuild_progr} ]] fakebuild_progr=100
fakebuild_progr=$(( $fakebuild_progr +1 ))
export fakebuild_progr
local fakebuild_ext=${1}.${fakebuild_progr}
# not sorting, break multiline vars
einfo ${fakebuild_output_dir}/env_${fakebuild_ext}
env \
${fakebuild_output_dir}/env_${fakebuild_ext}
# Remove egrep and sort to see the source of every fx
einfo ${fakebuild_output_dir}/fxlist_${fakebuild_ext}
typeset \
| egrep '^\b.* \(\)' \
| sort \
${fakebuild_output_dir}/fxlist_${fakebuild_ext}
}
This won't work as you expect. Env is a binary, it only gets
the exported env.
Elaborate on the what and when bit also, since the env that's dumped
to ebuild.sh varies depending on a lot of things.
~harring
pgprbcwHzA0vE.pgp
Description: PGP signature
Re: [gentoo-dev] Interactive emerge
On Mon, Oct 03, 2005 at 07:39:05PM +0200, Jan Kundr?t wrote: Ciaran McCreesh wrote: On Mon, 3 Oct 2005 23:15:37 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | Does it seem like it is time for RESTRICT=interactive. Such ebuilds | would refuse to emerge if stdout is not a tty. If only there was | use-flag based RESTRICT... No, because then that would encourage even more people to abuse the system and write incorrect ebuilds. IMHO this could be enforced by some policy (don't use RESTRICT=interactive unless you really need it and some_group has given you the ok)... Ebuilds are non-interactive compile/install... that's the design, and intention of them. I don't like opening the possibility for people to use it, mainly due to the fact A) give me an instance when it's required for compile B) interactive build scripts are idiotic (writing expect scripts for a tinderbox setup is proof enough of this) C) 15 hour upgrade/build, hanging an hour into it is going to be an ass biter. Yes, we can slap some warning into the UI tools for C, but people will still miss it on occasion, and it'll piss them off something fierce (just the same as a single failure in building results in emerge stopping). It's a bad idea from where I sit. ~harring pgpl89BfLrpEf.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] EAPI cleanups and fixes
On Tue, Oct 04, 2005 at 01:06:35AM +0900, Jason Stubbs wrote: Don't like the size of this patch, but it's quite repetitive so... Wouldn't worry on the repetitive, it's repetitive due to the fact the *dbapi classes don't (ab|)use inheritance... * Make all aux_get() functions return a list of strings again Why is this a good thing for EAPI? * Move the EAPI validity check into a separate function * Raise a specific UnsupportedAPIException instead of plain Exception * Mark metadata of unsupported EAPIs as INVALID rather than -1 This doesn't really fly imo. You mark it as invalid, and _no_ portage version (regardless of it's ability to handle that EAPI) will _ever_ regenerate that entry. An old portage version updating the cache would make certain nodes never usable. The -1 is wrong, should be -EAPI. This however is getting back into the eapi should be freeform, not just ints, which I thought I clarified why it should be ints (or people shut up instead of listening to me argue it). :) ~harring pgpF7iBOUVmQH.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] EAPI cleanups and fixes
On Tue, Oct 04, 2005 at 08:27:09AM +0900, Jason Stubbs wrote: On Tuesday 04 October 2005 03:30, Brian Harring wrote: On Tue, Oct 04, 2005 at 01:06:35AM +0900, Jason Stubbs wrote: Don't like the size of this patch, but it's quite repetitive so... Wouldn't worry on the repetitive, it's repetitive due to the fact the *dbapi classes don't (ab|)use inheritance... * Make all aux_get() functions return a list of strings again Why is this a good thing for EAPI? Consistency. There is no mapping of names to types so any tool that uses aux_get to enumerate values and assumes that they are strings (as they have always been and still are for every other key) would break. What tools are querying EAPI via aux_get already? I'm not much for making it a string purely because everything else is strings. * Move the EAPI validity check into a separate function * Raise a specific UnsupportedAPIException instead of plain Exception No problem with these two? Cleaner, so nope, no complaints. * Mark metadata of unsupported EAPIs as INVALID rather than -1 This doesn't really fly imo. You mark it as invalid, and _no_ portage version (regardless of it's ability to handle that EAPI) will _ever_ regenerate that entry. An old portage version updating the cache would make certain nodes never usable. The -1 is wrong, should be -EAPI. So negative numbers signals invalid cache entries in the scheme? sort of. Indication of what EAPI capable portage is needed that is capable of regenerating that entry correctly. This gets back to why the original patch was doing =0 tests. This however is getting back into the eapi should be freeform, not just ints, which I thought I clarified why it should be ints (or people shut up instead of listening to me argue it). :) The only reasoning that I recall without checking is that it wouldn't complicate certain code paths. That's not a valid reason, in my opinion. Can leave that debate alone though. s/INVALID/\-1/ in the patch works for me. -EAPI... -1 implies 3.x would be capable of regenerating it (may not be the case). It was partially code simplicity, but moreso it's sanity from where I sit. Refinements of specs, packages, projects, whatever, is numerical and increasing to indicate later revisions. EAPI=the horny toad ain't going to happen (nor should it), imo. ~harring pgpMgLIyZgHds.pgp Description: PGP signature
Re: [gentoo-portage-dev] Improved user information and communication
On Sat, Oct 01, 2005 at 11:57:01PM +0200, Daniel Stiefelmaier wrote: man emerge provides information on possible options, why should there not be a way to get information on an ebuilds option??? because emerge is the tool, not the object. You wouldn't expect the openoffice documentation to cover examples for different kinds of letters, would you? err.. i think you got me wrong... i do not expect emerge to have a built-in list of use flags. The description should be in the .ebuilds or metadata.xml But i hope you do agree, that eix or emerge are the appropriate tools to dig such information. Nope, I don't agree. (maybe eix more than emerge) Just like emerge -vv will print information about the ebuild maintainers in future release, if i got that right. Lifted from metadata.xml . Jamming a 'built-in list of use flags' into ebuilds/metadata.xml first of all is vague, second of all is going to jack up the tree's size, third of all will lead to a buttload of redundant information across the tree. So... nail it down, instead of the vague eix/emerge should do this. If you're suggesting it read use.* info from profiles/use.*, state so. The useflag xprint sounds like printing support, but doesn't tell if you need it if you use cups or the kde-printing system or... whatever. ~ $ grep xprint /usr/portage/profiles/use.desc xprint - Support for xprint, http://www.mozilla.org/projects/xprint/ what do you need more? - ease of use - elegance Eye of the beholder, not an objective point - not need to know about every portage file (especially if new to gentoo) - time efficiency (for dozens of flags) for x in flag1 flag2 flag3; do grep /usr/portage/profiles/use.*; done - non-global flags See above. eix also provides only information that you could grep in a more or less elegant way. or using google... Portage does you mean, since eix is just a tool that read directly from portage underlying files (and is going to get boned by portage changes to the underlying cache at some point). Use ufed, is my opinion on this, or write a tool/extension of existing tools. Why do you think just because YOU don't need it, noone will? This is not a personal debate. The most important reason I see against this idea is that portage is a package manager, not a documentation center. What you're not groking here is that people work on A) what they find interesting B) what they think *needs* to be done. Via that ordering, the subjective bit you're throwing out is nulled; use flag display is minor compared to fixing portage's screwups from where I sit. Additionally turning the question, Why do you think just because YOU think it's needed, others will? most programs, even those for gurus, print information about their option or AT LEAST how to GET information. still, these programs are not a documentation center. This makes no sense. Why should the ebuild contain links to documentation? To be honest, not even the HOMEPAGE info is needed, it's just for the user's convenience. even emerge is just for the user's convenience even distributions are just for the user's convenience, who needs them? i never heard someone argueing that a feature is needless because it is convenient. features are there to be convenient. Stretching the example to the extreme doesn't prove your point (don't do it if you want people to actually respond). I tend to refer to the UNIX principle: The right tool for the right job. For your problem, google (or any other search engine of course) is the right tool. what should i say? don't you have bookmarks of good sites? do you always google for them? of course you will get what you want in many cases but not always. another unix principle is that everybody can do everything the way he likes. in this case, i prefer to have a readers choice instead of googling and digging the perls. You've got the unix principle slightly wrong there- implicit is that if no alternative exists, the person persuing the alternative *implements* it themselves rather then riding others to do it. also, i agree that emerge may not be the right tool for that. may be eix or a new one. what this is about, is including additional information (only one link that will not hurt you) in the ebuilds or metadata.xml Guessing you're not aware of the cache, nor the dtd for metadata.xml Slapping stuff into the cache requires portage modifications, both for the package and for the rsync cache generation. It can be done, but the question before doing it is exactly what this is going to yield, is it really the right route, and what is going to be broken by this (since tools *do* read directly from cache entries even if it's daft to do so). Do you think we're all sadists? No, but hard to believe that you are not ignorant against people - that like to have features you personally find useless - that may be not using linux since
[gentoo-dev] deprecation of SANDBOX_DISABLED
Hola. Subject says it all; SANDBOX_DISABLED functions as (essentially) RESTRICT=sandbox, except sandbox is left on for pkg_setup . This is pretty much redundant, considering it's usage. People stick it in the global scope; if you _must_ turn off the sandbox for a specific phase, use SANDBOX_ON=0/1 instead. If you need to disable sandbox across the board, restrict=sandbox is your friend. Since there are still ebuilds in the tree that would be schmooked by it, it's not going to hit in the coming version, but I'd expect it to be dead next version after unless people have a really good reason why it should live on. So... thoughts? Yes it's minor, but it's a matter of cleaning up/simplifying portage code, and removing redundancy. ~harring pgpWyUB9DfcVy.pgp Description: PGP signature
Re: [gentoo-dev] How to create SRC_URI from messed-up URL?
On Thu, Sep 29, 2005 at 12:46:36AM -0400, Dave Nebinger wrote:
Hey, folks.
I'm trying to write an ebuild, not my first, but definitely something
that is relatively new to me.
Anyways, I've got the following URL that pulls down the source package:
http://www.fpdf.org/en/dl.php?v=153?f=tgz
The file that gets downloaded is fpdf153.tgz.
Well, that messed up dl.php?... stuff results in the file
/usr/portage/distfiles/dl.php?v=153?f=tgz rather than the fpdf153.tgz
that I need it to be called.
So how do I 'trick' portage into downloading the file from the given
link to the fpdf153.tgz file I want to have?
You don't. It would require addition of ${FILE} to the
(FETCH|RESUME)COMMAND vars.
Or am I stuck with the fetch restriction and have the end-user download
the file manually?
Note in the bug that you submit this ebuild in, that the file needs to
be downloaded and uploaded by a dev (with the SRC_URI changed over to
mirror://gentoo/fpdf153.tgz). Please don't attach the src for the
pkg, just tag the url for it into the bug :)
It sucks, but it's the usual way of dealing with screwy upstream urls.
~harring
pgpsrEa75mL5d.pgp
Description: PGP signature
Re: [gentoo-dev] Dirt: To shove under the rug or not shove under the rug? (aka another round of USE_EXPAND)
On Tue, Sep 27, 2005 at 09:07:00AM -0500, Kito wrote: [Portage devs please don't throw rocks at me] All out of rocks :/ My impression of the userland, elibc, and kernel use expanded vars is it was a quick way to sidestep some of the issues with GLEP22... it would seem the full keywords have still not been taken advantage of. From the ebuild perspective, if the profile has a keyword of x86- fbsd-bsd-fbsd, there is no clean way to just do a conditional based on a 'Keyword Fragment' as there are obviously namespace collisions. Ideal to me would be syntax something like: kernel !fbsd foo libc glibc || bar userland darwin boof Bash side of it's pretty easy to implement however needed, the problem here (and why imo USE_EXPAND came into existance) is getting those conditional nodes into the dep syntax evaluation without trampling other use vars. And *-*-*-fbsd as a conditional node sucks in depends, is ugly, oh so ugly. :) ~harring pgpTMeW117Yze.pgp Description: PGP signature
Re: [gentoo-dev] default logger
On Tue, Sep 27, 2005 at 08:27:34AM -0400, Chris Gianelloni wrote: On Tue, 2005-09-27 at 10:39 +0200, Henrik Brix Andersen wrote: On Tue, Sep 27, 2005 at 10:31:04AM +0200, Jan Kundr??t wrote: our documentation [1] lists syslog-ng as the default system logger while current profiles uses metalog (except embedded, default-macos/ppc, default-darwin and sparc32). What should be changed, Handbook or profiles? I think we should recommend syslog-ng over metalog, both in documentation and in profiles, due to the fact that most software, howtos and tutorials expect the system log to be located in /var/log/messages Most software howtos, and tutorials about init scripts don't apply to _our_ init scripts. Nor do any howtos/tutorials for other pkg formats, apply to _our_ pkg manager. ;) Agreed. It should be syslog-ng. If nobody objects, I'll change it in base/virtuals. Objecting, obviously ;) Basically... why? I'm neither advocating being different to be different, nor following others so howtos about their stuff fit to ours. I'm after the underlying reasons why general users should be using syslog-ng over metalog in contrast to the fact we've recommended metalog as long as I've been around. That and I happen to like metalog's layout, strangely enough ;) I'd rather see reasons listed as to why syslog-ng is a superior default for users who (most likely) don't care, then we lack /var/log/messages :) ~harring pgpEpA6MHbHXz.pgp Description: PGP signature
Re: [gentoo-dev] default logger
On Tue, Sep 27, 2005 at 01:47:49PM -0400, Mike Frysinger wrote: On Tuesday 27 September 2005 01:29 pm, Chris Gianelloni wrote: On Tue, 2005-09-27 at 11:57 -0500, Brian Harring wrote: I'd rather see reasons listed as to why syslog-ng is a superior default for users who (most likely) don't care, then we lack /var/log/messages :) Besides the /var/log/messages thing, which I think is a non-argument, there is syslog-ng's ability to be usable by anyone. It works great for servers, it works great for desktops. It works as a loghost. It works for remote logging. Essentially, it has all of the features that users would want. It also has all of the features that administrators would want. It is flexible and powerful. how exactly is this an argument for syslog ? metalog has all these features (and more) except for remote logging ... Additionally, metalog (afaik) won't be depending on glib, like =syslog-ng 1.9. Keep in mind I'm talking only defaults here (iow, use whatever is best for your needs). Re: it being a temporary change that should be undone, it's been around long enough I won't call it 'temporary' at this point. Merits vs well, we recommend/did this a while back and were going to reverse it mainly. ~harring pgpiRTbptQS1W.pgp Description: PGP signature
[gentoo-dev] portageq in global scope == die
Hola all. The short version of it is that there is no good reason to be using has_version/portageq in the global scope; it's slow, it's not allowed, and any attempts to change metadata via it screw up the build plan. It's really a no go... so next version of portage will trigger an immediate die whenever portageq is called in the global scope. Won't be possible to pull it off globally, in other words. The logic for this comes down to the reasons raised above; mainly, it's a snake in the grass for bugs. Those affected by it I've filed bugs against (check your email iow); in the meantime, giving people a heads up on this one. ~harring pgp2QMx8HVhH5.pgp Description: PGP signature
Re: [gentoo-dev] Commercial software in portage
On Thu, Sep 22, 2005 at 09:30:20AM -0400, Chris Gianelloni wrote: On Wed, 2005-09-21 at 17:55 -0500, Lance Albertson wrote: Is this just a one-off implementation until GLEP 23 is implemented, or something that will complement it? Whats going to happen to this data after GLEP23 gets implemented? I'd hate to see something added simply because its a quick one-off solution to make something work. I'd rather see people focus on the actual GLEP and moving it along. Of course, if this data will just be an added feature of GLEP23, I don't see a problem. This really has nothing to do with GLEP23, as it isn't related to any kind of grouping, or ACCEPT_LICENSE. It is simply a marker to say to our users: Hey, you have to buy this for it to work. That is something that GLEP23 does not provide for in any way. Actually, it does have to deal with glep23, and you already stated in one of you emails (an interim solution *now* since I've not heard anything from GLEP23 for some time). Further, where do you think you're going to migrate the check for this license to? FYI, accept_license checks have been sitting in svn/cvs for about a month, same as use deps. No, you can't use them now in a released portage, but that's not much of a reason to introduce a fake license I'm sitting. Further, a better approach instead of people adhocing yet another band aid in the tree would be to chip in- you want glep23? help bring the *proper*, agreed upon solution to a stable portage, not taking the easier route. The suggested intention of this fake license is also a bit daft imo; what is LICENSE, the metadata? The license the underlying pkg is released under. Commercial is supposed to be mean it costs money, well, how are you going to deal with opera? Flip off the commercial license now? The original proposed angle (glep23 implementation isn't here) is jumping the gun, and the angle of it indicates it costs money isn't proper either. You want to indicate that this *specific* pkg costs money (something not related to the license it's released under I might add)? Stick it in metadata.xml or DESCRIPTION. License has a specific meaning- aside from the fact you're shoving an additional license requirement on people when glep23 hits, you're also blocking anyone from using that as a license group do to the fact you already introduced a psuedo license in instead of a *proper* groupping. So... my 2 cents? No (was obvious already, wasn't it? :) ~harring pgpyrjkHj2ltZ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Tue, Sep 20, 2005 at 10:01:39AM +0300, Alin Nastac wrote: Georgi Georgiev wrote: maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. So that's why my overlay got screwed up! But seriously, this only supports my point -- category moves are evil. portage isn't supposed to offer eternal functionality status for personal overlays. Eh? what if an eclass gets obsoleted and eventually is removed from the tree? Pull from viewcvs. I assume you're talking about portage =2.1 capabilities, since you *cannot* remove an eclass from the tree once it's been added currently. the only problem is binary packages screw up. Binpkgs should be running from their own env, they should be stand alone not requiring even a tree. Back on subject... I *really* don't like categories. Single vdb, single repo, single binpkg, it's not horrible. Multiple true, standalone repos, with the occasional binpkg repo used? It makes doing the category move *really* rather hard, since you need to track down exactly which repository and ebuild came from. ~harring pgp81JlK7zAMI.pgp Description: PGP signature
Re: [gentoo-dev] Resolution - GTK Useflag Situation
On Sun, Sep 18, 2005 at 03:48:43PM +, John N. Laliberte wrote: * but you are taking away choice! - If a program has both GTK2 and GTK3 interfaces, there are many ways to allow for testing of the experimental interface. For instance, package.mask with a revision number. package.mask isn't a perfect fit from where I sit; if it's already merged (say for development), but the developer has masked gtk-3, all pkgs that prefer gtk-3 will continue linking against it till gtk-3 is unmerged regardless of the masking. Part of the reason I prefer use flags here; aside from that, use flags aren't features, strictly conditionals (intentionally vague) :) * use the proper, built in methods for this: add =x11-libs/gtk+-1* to /etc/portage/package.mask. If merged, need to unmerge it to block any further linking to it if using || () deps. Issues above aren't blockers at all, just pointing it out since it does have a minor downside, one that should be mentioned in any documentation that tells people how to migrate from gtk(N-1) to gtkN. There are some downsides that should probably be made clear. ~harring pgpyaKMH69fBY.pgp Description: PGP signature
[gentoo-portage-dev] PATCH glep31 checking
Hola.
http://glep.gentoo.org/glep-0031.html-- the details
http://bugs.gentoo.org/106544-- the bug
http://bugs.gentoo.org/attachment.cgi?=68828 -- the patch
Attached the patch also; one additional tweak is that file.size is now
a fatal check, since the tree seem's to finally be clean.
~harring
Index: repoman
===
--- repoman (revision 1992)
+++ repoman (working copy)
@@ -13,6 +13,13 @@
sys.path = [/usr/lib/portage/pym]+sys.path
version=1.2
+allowed_filename_chars=a-zA-Z0-9._-+:
+allowed_filename_chars_set = {}
+map(allowed_filename_chars_set.setdefault, map(chr, range(ord('a'),
ord('z')+1)))
+map(allowed_filename_chars_set.setdefault, map(chr, range(ord('A'),
ord('Z')+1)))
+map(allowed_filename_chars_set.setdefault, map(chr, range(ord('0'),
ord('9')+1)))
+map(allowed_filename_chars_set.setdefault, map(chr, map(ord, [., -, _,
+, :])))
+
import string,signal,re,pickle,tempfile
import portage
@@ -21,6 +28,8 @@
import portage_dep
import cvstree
import time
+import codecs
+
from output import *
#bold, darkgreen, darkred, green, red, turquoise, yellow
@@ -85,6 +94,8 @@
filedir.missing:Package lacks a files directory,
file.executable:Ebuilds, digests, metadata.xml, Manifest, and
ChangeLog do note need the executable bit,
file.size:Files in the files directory must be under 20k,
+ file.name:File/dir name must be composed of only the following
chars: %s % allowed_filename_chars,
+ file.UTF8:File is not UTF8 compliant,
KEYWORDS.missing:Ebuilds that have a missing KEYWORDS variable,
LICENSE.missing:Ebuilds that have a missing LICENSE variable,
DESCRIPTION.missing:Ebuilds that have a missing DESCRIPTION
variable,
@@ -146,7 +157,6 @@
IUSE.invalid,
ebuild.minorsyn,
ebuild.badheader,
-file.size,
metadata.missing,
metadata.bad,
virtual.versioned
@@ -663,6 +673,29 @@
stats[file.executable] += 1
fails[file.executable].append(checkdir+/+y)
digestlist=[]
+
+ for y in checkdirlist:
+ for c in y.strip(os.path.sep):
+ if c not in allowed_filename_chars_set:
+ stats[file.name] += 1
+ fails[file.name].append(%s/%s: char '%s' %
(checkdir, y, c))
+ break
+
+ if not (y in (ChangeLog, metadata.xml) or
y.endswith(.ebuild)):
+ continue
+ try:
+ line = 1
+ for l in codecs.open(y, r, utf8):
+ line +=1
+ except UnicodeDecodeError, ue:
+ stats[file.UTF8] += 1
+ s = ue.object[:ue.start]
+ l2 = s.count(\n)
+ line += l2
+ if l2 != 0:
+ s = s[s.rfind(\n) + 1:]
+ fails[file.UTF8].append(%s/%s: line %i, just after:
'%s' % (checkdir, y, line, s))
+
if isCvs:
try:
mystat=os.stat(checkdir+/files)[0]
@@ -799,6 +832,13 @@
stats[file.size] += 1
fails[file.size].append((+
str(mystat.st_size/1024) + K) +x+/files/+y)
+ for c in y.strip(os.path.sep):
+ if c not in allowed_filename_chars_set:
+ stats[file.name] += 1
+ fails[file.name].append(%s/%s: char
'%s' % (checkdir, y, c))
+ break
+
+
if ChangeLog not in checkdirlist:
stats[changelog.missing]+=1
fails[changelog.missing].append(x+/ChangeLog)
pgpoxv44vqNjL.pgp
Description: PGP signature
Re: [gentoo-portage-dev] PATCH glep31 checking
On Mon, Sep 19, 2005 at 04:12:08PM -0500, Brian Harring wrote: Attached the patch also; one additional tweak is that file.size is now a fatal check, since the tree seem's to finally be clean. Dropped the file.size becoming fatal change on the bug, and intend to for the final version. Either tweak the patch yourself, or gank it from the bug... it's a one line reversion. :) Pls test, kthx. ~harring pgpSn9miVa1jT.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote: The 30-day could be calculated from the $Header: of ebuilds that have no UNSTABLE, or where it's empty. Doesn't work for N arches keywording, or ebuild dev doing minor syntax touch ups. ~harring pgp9GsjkqH1mC.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, Sep 16, 2005 at 08:14:08PM +0200, Martin Schlemmer wrote: On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote: On Friday 16 September 2005 00:20, Mike Frysinger wrote: actually this is came up in the meeting as something we would like to see spelled out explicitly ... either as a GLEP itself or as a policy update to current stabilization practices the GLEP was approved on the grounds that we need an x86 team and that it needs to be treated as any other arch ... arch team interaction with maintainers should be spelled out clearly rather than part of a single sentence '... or make individual arrangements with the x86 arch team.' Ok, I do think that we will need a way for the maintainer to indicate that the package is stable. I'd be happy to leave stabilizing out of my hands, but I wouldn't want my packages to be stabilized before I deem it stable. File a bug if the arches (or main ones at least) haven't picked it up yet? Will make the problem of missing some or other keyword minimal (especially for some obscure package not often used). I would prefer this route, personally. Jamming a maint keyword into the ebuild is kind of ugly from where I sit :) ~harring pgp1E2oHKfzdH.pgp Description: PGP signature
Re: [gentoo-dev] Clarification of packages cd's for 2005.1
On Sat, Sep 17, 2005 at 08:23:47AM +1200, Nick Rout wrote: Thanks for the clarification Chris. On a semi-related matter I was looking for the catalyst .spec files, and see a thread pointing at cvs, however I believe that as a non-dev mortal I can't get access to gentoo cvs. Is that so? If it is then how does one get the spec files? The old catalyst howto seems to have disappeared too. http://www.gentoo.org/cgi-bin/viewcvs.cgi Is a start ;) ~harring pgp0iks5YMa4J.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
On Wed, Sep 14, 2005 at 04:38:04PM +0100, Ciaran McCreesh wrote: On Wed, 14 Sep 2005 09:42:43 +0200 Thierry Carrez [EMAIL PROTECTED] wrote: | Before debating if the QA team should have more power to enforce, | let's just have a proper QA project. Apparently not much devs want to | do QA, not sure telling them they will do QA+police will help in | motivating them. Part of the problem with that is that people who *would* normally do QA think it's pretty much futile right now anyway, since the worst offenders just carry on breaking things no matter how often they're asked to stop... I'd agree; this is the reason I stopped auditing eclasses a year back. We've had bugs where flat out invalid deps (DEPEND dependant on has_version calls) sat for 2 years, *despite* QA/portage devs laying it on thick that this is totally invalid. That's not even getting into user complaints. There are people doing QA, the problem historically has been getting people who don't care to fix their stuff. That's a *really* quick way to burn out people doing QA; the fact that there is a problem, but they have no means beyond nagging to get the offender to fix their mess. There's only so much nagging one can do before they say screw it, and wander off to do something a bit more productive. If QA actually had some power beyond a pissed off member complaining to devrel, I'd expect you would see those burnt out by past attempts starting again. I'd be game for resuming auditing of eclasses, personally. ~harring pgpXJE0VcrbNg.pgp Description: PGP signature
Re: [gentoo-dev] Bug 80905
On Tue, Sep 13, 2005 at 03:24:38PM +0200, Frank Schafer wrote: Hello, this bug is from 2005-02-05. It was reported again (in this thread) 2005-02-10. I hit the same behavior 2005-09-08. internal compiler error: segmentation fault during emerge Xorg The bug is simply reproducible (emerge Xorg) at the same line of code. The bug is still marked as NEW. Donnie Berkholz replied 2005-02-10 with: Could you humor me and try with a vanilla kernel? My questions here: Does someone have a look at this? I think a not installable Xorg is severe enough to mark it as CRITICAL. Does someone know if it's worth a try with the vanilla and if vanilla here means a really vanilla from kernel.org or if it's sufficient to get the (too patched and thus not so vanilla) vanilla-sources. Please be kind with me regarding to the fact that I'm posting here. On the gentoo mailing list I get only replies like: You probably have faulty memory. If THIS would be the fact the bug would show up randomly in different ebuilds or at least at different lines of code. Granted Donnie is a miserable so and so, but his advice is accurate. To get an ICE (what you're getting) requires either 1) faulty hardware. proc going nuts, mem going nuts 2) faulty kernel 3) faulty toolchain Reproducability of a failure across reboots kind of indicates 1 as not being the case, leaving 2, and 3. ICE's are pretty much *never* the fault of the source; the source may expose a toolchain bug, but it's not the sources fault. You don't blame an email for crashing your email client, you blame your email client for horking up and segfaulting, instead of gracefully failing in the face of potentially wrong input. Note I'm not stating the source is the fault here, just trying to clarify that ICE's pretty much are indicative of hardware/kernel/toolchain being nuts, not the source that's being compiled. So... try his suggestion. Yes it's annoying, but frankly addressing your issues here pretty much requires poking at the options above, seeing if one of them makes compilation stop ICE'ing. If it does, then you back track and figure out what changed... etc. ~harring pgpyVFvvjd4As.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
On Tue, Sep 13, 2005 at 05:02:45PM -0400, Mike Frysinger wrote: On Tuesday 13 September 2005 04:43 pm, Donnie Berkholz wrote: Mike Frysinger wrote: this side note is unrelated to the point being made and really belongs in the previous discussions on the devrel list besides, is this a bad thing ? i'd prefer to have devs settle crap themselves than ever contacting devrel :P It's very relevant, because it supports the idea of QA taking care of technical issues on its own. QA can work faster since it's less objected do and doesn't need endless committees and documentation -- the documentation is the broken code. QA team does not care at all about inner workings of devrel QA team identifies a misbehaving dev who refuses to change and then hands off the name/relevant data to devrel ... QA team then is pretty much done with the issue and the rest is up to devrel to resolve Pretty much is what I'm after; just want to ensure no more scenarios where stuff gets left broken for 18 months (actual example) due to QA having no means to force people to fix their cruft. This need a proposal, or can the council just do a make it so ? ~harring pgpNdXWnwxORt.pgp Description: PGP signature
Re: [gentoo-dev] Portage log suggestion
On Mon, Sep 12, 2005 at 02:13:43PM +0200, Frank Schafer wrote: Hi, I fought with a stage1 install during this weekend. Today in the morning I succeeded. I had to move a lot in /var/log/portage. For the content of this directory I'd suggest the following: Remove the 4 digit number from the log file names. They're relevant to portage stable; down the line it'll likely be mtime based. Right now that 4 digit number is an internal incrementing counter that's tagged into the log file name. It is a good idea to have 2 files for each package. One with the output of make and one with the messages for the installer. Name the former package-version.log and the latter package-version.msg Doesn't work that way, and what you're after (restating your 'installer' as enotice/ewarn/einfo) is elog, something that'll be in the next major version. You're seeing two logs due to the fact you have FEATURES=buildpkg on; effectively, portage build's the binpkg (log 1), then merges it (log 2). This is inneficient though, since it builds up one $IMAGE dir, binpkg's it, then dumps it to another dir and installs from that. That's an old annoyance that should die a miserable death soon enough. ~harring pgphQlVMr4tls.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
Top posting, since trying to make a point here in relation to everything that follows from your email. define exactly how one proves themself, and in what context. It's the arguement against (essentially) having AT's on the same level as ebuild devs, so it best be defined. On Tue, Sep 13, 2005 at 04:14:34AM +0100, Ciaran McCreesh wrote: On Mon, 12 Sep 2005 23:01:20 -0400 Alec Warner [EMAIL PROTECTED] wrote: | I'm not confusing anything here. Arch Devs ( ala members of arch | teams ) and Arch testers should be equal in terms of developer | status. Why? Arch testers *aren't* full developers. They may become them, but they haven't yet demonstrated that they're capable of being a full developer. | voting previleges Again, why? They have not yet demonstrated their understanding of complex technical issues. Voting should be restricted to people who know what they're doing. Arch testers have not yet proven themselves. | Assuming by arch dev you mean arch tester, then: | | Experience, commitment and (at least in theory) recruitment | standards. | | Commitment first: | IMNSHO, it is rude to assume that an Arch Tester is less commited to | their work than an Arch Team member. All developers should be doing | their part and should hopefully ( we don't live in an ideal world here | after all ) be commited to doing their work well. A lack of | commitment that results in shoddy work should get them removed from | any developer role, Arch Team member or otherwise. An arch tester has not committed himself to the project for the same length of time as a full developer. | Being a Gentoo developer isn't ( or I should say, shouldn't be ) all | about what happens in CVS. There are many people who support other | portions of gentoo forums/bugs/devrel/testing/user | relations/gentooexperimental.org/etc and some sort of stupid elitism | about being a better dev or a dev that has better skillz because | said dev has commit access is simply stupid. Devs with commit access | may be skilled in the workings of the tree ( and there are certainly | devs with commit access that do not possess such a skillset ), but | that should be why they have commit access, because they possess the | skills to manage the tree. Uhm... Different people have different skill levels. Some of this is down to natural ability, some of it is down to experience. Arch testers have not yet proven themselves. Full developers have (at least in theory...). | Personally I would rather see people's CVS commit access by | herd/package/section than just generic tree access. Commiting | something outside your Role becomes then contacting someone who knows | what they are doing and who can look over your work (good!). The bad | part being when no one is around who has commit access. A resolution | for this situation would need to be required. Expections would need | to occur as well ( tree-wide commits, and other things that happen | from time to time ). However I'd like to see more input on things | like this ( along with say, council approval? :) ). Take a look at the branches proposal that's been floating around. It's basically what you suggested with fewer holes and a more realistic view of how development gets done. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm ~harring pgpvx1v3OLjWE.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
With the 'proven' definition being repeated contributions, and explicit in the previous email the view AT's are lesser, but can move 'up' to the level of an ebuild dev, back to this email... On Tue, Sep 13, 2005 at 04:14:34AM +0100, Ciaran McCreesh wrote: On Mon, 12 Sep 2005 23:01:20 -0400 Alec Warner [EMAIL PROTECTED] wrote: | I'm not confusing anything here. Arch Devs ( ala members of arch | teams ) and Arch testers should be equal in terms of developer | status. Why? Arch testers *aren't* full developers. They may become them, but they haven't yet demonstrated that they're capable of being a full developer. Arch devs != ebuild devs != ATs They're different roles. Stop intermixing them, unless you're going to start throwing portage devs, doc devs, infra, and devrel in. There _is_ a common subset to portage devs, arch devs, ebuild devs, and ATs, but that does not mean they're equal in requirements and roles. Each has a role, don't blur the AT definition into ebuild devs unless you've after eliminating AT positions (something I doubt going by your previous QA threads); if you're after that, state so please. | voting previleges Again, why? They have not yet demonstrated their understanding of complex technical issues. Voting should be restricted to people who know what they're doing. Arch testers have not yet proven themselves. Have doc devs demonstrated their understanding of complex technical issues? Portage devs? Infra? Your metric frankly is rather vague. Come up with one applicable to AT's rather then vague terms impying AT's are not of the 'elite' ebuild dev standard please. Additionally, Note that those proposing the glep utilize AT's in their arch; they may have a different view of role/ability of the AT's then you do, and of their abilities. IOW, nail down your metric, then apply it to the existing AT's (since they are what we have to work with), and then re-raise your views that they don't know what they're doing. Back to the complex technical issues, point I'm getting at is that the problem domain of both differ, even if they may have a common subset. | Assuming by arch dev you mean arch tester, then: | | Experience, commitment and (at least in theory) recruitment | standards. | | Commitment first: | IMNSHO, it is rude to assume that an Arch Tester is less commited to | their work than an Arch Team member. All developers should be doing | their part and should hopefully ( we don't live in an ideal world here | after all ) be commited to doing their work well. A lack of | commitment that results in shoddy work should get them removed from | any developer role, Arch Team member or otherwise. An arch tester has not committed himself to the project for the same length of time as a full developer. This is mild BS, since it's a common issue to all classes of gentoo volunteers. Further, stats provided (as were requested) I'd posit are actually better then ebuild dev stats, although worth noting the sampling period differs. | Being a Gentoo developer isn't ( or I should say, shouldn't be ) all | about what happens in CVS. There are many people who support other | portions of gentoo forums/bugs/devrel/testing/user | relations/gentooexperimental.org/etc and some sort of stupid elitism | about being a better dev or a dev that has better skillz because | said dev has commit access is simply stupid. Devs with commit access | may be skilled in the workings of the tree ( and there are certainly | devs with commit access that do not possess such a skillset ), but | that should be why they have commit access, because they possess the | skills to manage the tree. Uhm... Different people have different skill levels. Some of this is down to natural ability, some of it is down to experience. Arch testers have not yet proven themselves. Full developers have (at least in theory...). Not much for the natural ability bit/elitist stuff; the question is what they've demonstrated, the work done. Doesn't matter if it takes a person 20 hours, or 1, it's the end product people see, and what ultimately matters (as you've pointed out in re: to QA). Beyond that, I don't agreew with the Arch testers haven't proven themselves. They wouldn't be marked as AT's by the arch if they hadn't demonstrated some form of worth, just the same as ebuild devs aren't recruited if they haven't shown some form of worth (this includes ability to stick around for more then a month). Screwups happen, but the stats offered are a pretty good indication they've got that angle addressed imo. The only bit I'd actually disagree with on the glep is the 2 weeks period for conversion of an AT to an ebuild devs; the two roles (imo) are seperate, those handling ebuild devs should set the requirements themselves, just the same as those handling AT devs should set the requirements they perceive as needed. My 2 cents? They're doing work for gentoo.
Re: [gentoo-dev] Comparing Openpkg with portage
Icky on the html email :P On Wed, Sep 07, 2005 at 05:45:16PM -0700, m h wrote: Hello- I'm investigating the similarities between portage and openpkg. More specifically I was wondering if it is possible to take portage and install in on top of an existing linux installation in its own sandbox s/sandbox/prefix/ This is what fink does, and what gentoo-osx is moving towards. (similar to what openpkg does). I've done some googling and found the documentation about the gentoo sandbox ([1]http://bugday.gentoo.org/sandbox.html), but this seems to be a tool for checking that ebuilds behave correctly. Moreso protection, then ensuring they behave correctly; if they do something they shouldn't they get blocked from what they're attempting. It's an active tool, rather then a 'check' of the ebuild (that and it's limited to linux, no *bsd implementations). Akin to depriving, although depriving is more effective- one can sidestep the sandbox, can't sidestep being de-prived aside from priv escalation. I've read through the developer documentation and didn't find anything there. Google hasn't necessarily been very useful either So, is it possible to sandbox a portage installation on top of say a debian or fedora install? If so, can anyone point me in the right direction? With current ebuilds, nope. There's no global prefix offset in the code for it (root is merge offset, not runtime prefix offset). Do any of the devs out here have experience with openpkg? Pretty much an extension of rpm spec's, afaik. Beyond that? Heh, nope :) ~harring pgprNbXWpws3d.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Fri, Sep 02, 2005 at 10:53:05AM +0200, Paul de Vrieze wrote: On Friday 02 September 2005 08:04, Brian Harring wrote: Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi defines revisions of it, in my mind a minor revision of the ebuild 1 format. Any form of loss of backwards compatability *should* be a different format, .ebuild2 for all I care. The new proposed format loses backwards compatibility. If there is backwards compatibility no new format or api version is needed. EAPI should work on the python level, not only on the ebuild.sh level. The two are utterly intertwined. Doesn't matter if portage thinks it's eapi 1 or 2, what matters is if the ebuild*sh env *creates* an eapi 1 or 2 env for execution. Python side just behaves a bit differently, ebuild*sh is where all of the actual execution occurs (and varies dependant on eapi). Trying to use EAPI to allow for N different formats into one format is wrong from where I sit; you would need a container format for it, which ebuild wasn't designed for (nor is it easily extensible to be made so I posit). No it would state that the eclass is 100% compatible with both by the formats overlapping and the ebuild not threading outside the overlapped area. And how is this going to work when it's more then just a split of a func? I'm not saying it can't be done, I'm saying it *shouldn't* be done. It's begging for screwups; relying on portage to pick and choose between eapi levels for an ebuild's execution env dependant on an eclass *requires* the ebuild to be fully compatible to those eapis, same for the eclass author. That's not so easy to do, and will lead to a buttload of case tests of EAPI, which isn't going to improve the code (imo). People aren't going to do it, is my opinion. It's unnecessarily complex with minimal gain; the gain being decreased due to the inherent complexity of A) pulling this off in portage B) comprehending *exactly* what portage will do in each case C) the ebuild/eclass author not only managing to get usage of *one* eapi correct, getting potentially N eapi's correct. D) eclasses that inherit eclasses requiring the same eapi compatability checks E) within two bodies of code, devs keeping seperated in their mind the differences between each eapi, and *never* blurring them. Note I'm not pulling the everyone else is ignorant crap that popped up on -dev ml; I'm stating that writing to an api is manual work, and people will screw up on it, just the same as in writing the implementation of that api, *we* will screw up on it. Bugs per line, it's unavoidable. Not advocating that we dumb everything down, advocating we don't add something that (assuming we get it right in implementation) is one hell of a pandora's box from the standpoint of complex ebuilds combined with complex eclasses. That's also not even getting into the fact that what you're proposing, effectively greping EAPI from the file is A) helluva lot slower on regen B) trying to turn ebuilds into a container format. They're not a container format, nor should they be (kitchen sink shouldn't be included). C) core's more then capable of supporting seperated formats; the 'container' should be the repository, not jammed within the package data. D) It's a helluva lot easier, and less chance for screwup to just define a new format, use a new extension, and have the repository implementation use a different pkg format for that file. E) New, non eapi=1 style change with a different extension wouldn't even be *seen* by the noncompliant repositories. Helluva lot simpler. Not advocating we define a new format every day; I'm advocating that we define a format (v1), we do tweaks to it, and define a new *seperate* format when we need stuff that is beyond the keen of the existing format. Shifting away from declarative syntax, moving away from bash syntax, etc. If it isn't akin to our existing definition of an ebuild, it's not an ebuild and should *not* be jammed into the ebuild format. It's a new beast, and should be seperated. That's also ignoring the additional interaction of elibs thrown into the mix. If what you're suggesting is implemented, eclasses *and* ebuilds would be litered with if [ $EAPI == 2 ]; then eapi2 specific stuff elif [ $EAPI == 1]; then eapi1 specific stuff else general, all eapi stuff fi Note that the code above also has a nice hidden bug in it that's not obvious till you think about it; there is no way to predict at the time of the ebuilds writing that EAPI3 will work for the else block, yet logic structures of that sort *will* exist if you open up the N EAPI compatibility for an ebuild/eclass. Any bumping of the potential eapi's for an ebuild/eclass will expose it. That and I'd hope if it were ever implemented, devs would be using functions within the logic block; even with, any non-trivial bit
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 03:42:25AM -0500, Brian Harring wrote: Hola all. Straight to the point, I'm proposing that the following files- arch.list categories use.desc use.local.desc package.mask updates Addition to this list: thirdpartymirrors . ~harring pgpvIGSGfwz7G.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Tue, Aug 30, 2005 at 07:46:24PM +0200, Marius Mauch wrote: On 08/29/05 Brian Harring wrote: That and the fact the 2.1 state should be decided, if we're going to have (effectively) two branches of development going at once, vs developmental line and maintenance branch. Well, basically I wanted to deploy elog and Jason mentioned some other changes as well, and while talking about it we couldn't find much in head that we didn't want out. Unfortunately you weren't around at that time. Also I think we could use 2.1 to add all the hacks we need for transitioning (like the EAPI and Manifest stuff). I'd rather tag the hacks into stable release, as what the EAPI patch is intended to do. Reasoning is pretty straightforward; I trust stable code to hold less user visible bugs now, then what 2.1 would hold- stable has been shoved through the ringer; 2.1 hasn't been shoved through a comparable ringer. Further, if we're tagging compatibility hacks for 2.0.51 - 3.0, the thing that matters is the compatibility additions, not extra (potentially buggy) features. Don't get me wrong- I'm still watching 2.1 bugs, but mainly for correction of stuff w/in rewrite. 2.1 *could* be made into a full release line, I just am convinced the time to do so has come and gone already. Rewrite isn't complete, but the base of it is saner then 2.x's, and people (beyond me) are actively working on it. Further, people are sniffing around re: capabilities the rewrite has natively, N portdir's for example for the -osx crew. My 2 cents, at least. ~harring pgpskUMjjL4Mq.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] gtk/gtk2 USE flag annoyances
On Fri, Sep 02, 2005 at 07:58:05AM +0200, Marius Mauch wrote: On 08/26/05 Brian Harring wrote: On Fri, Aug 26, 2005 at 11:44:44AM -0400, Dan Meltzer wrote: Hows the upgrade path RE: end-user useflag changes? Will everyone that has gtk in their make.conf die a horrible death if they don't see the upgrade notice? when will they see the upgrade notice? Would it make sense to leave the gtk flag for a while at least, to ease the end user into an upgrade? Not saying it's a clean idea, but aside from making a lot of noise about the change over (which should be delayed till that noise has been made), a base/profile.bashrc trick of substituting gtk in when gtk1 is detected would work. Hell no. Don't need to add more confusion to the use flag confusion. Instead, confuse the hell out of users who don't religiously follow -dev/-user/-gwn, and suddenly get bit by the gtk flag losing it's meaning? That said, it won't work anyways; the aliasing has to occur within the python side else it'll screw up the depgraph (realized that just a few seconds ago) :) So... back to making a lot of noise, or some python side support for aliasing use flags. ~harring pgpfNB2mFzyUY.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote: On 08/27/05 Brian Harring wrote: Straight to the point, I'm proposing that the following files- arch.list categories use.desc use.local.desc package.mask updates be moved out of the profiles directory in the tree, and into the existing metadata directory personally, due to the fact that the files above are essentially repository metadata. Why move them *now* when they've been around forever? [snip] Don't mind moving them, BUT - metadata is a stupid location for them for several reasons being? metadata already holds global repository information, time of repositories generation, pregenerated cache, glsa set... It holds global metadata for the repository. - don't really like adding more cruft to the regen script Agreed. That said, users bitching when the don't upgrade their tools, and said tools start breaking isn't fun. - why move them now and then move/redesgin them again when someone finally makes a sane profiles design (yeah, I've talked about that for months now :-/) Anyone after redesigning profiles has their hands full. Do this change now, profile redesign isn't burdened with dealing with this mess. This change over as indicated in other postings to this thread also would prepare for allowing full capabilities to standalone repositories, rather then coming up with a hack that pulls the data from profiles. The change over can be done pretty cleanly, and organizes stuff as it should be, in preparation of upcoming tweaks/capabilities/whatever. I'd rather nip this now, rather then when it starts creating problems down the line. ~harring pgpMOXARvsGs3.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, Aug 29, 2005 at 12:56:35PM -0400, Chris Gianelloni wrote: On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote: Basically, you've taken then 2005.1 profile and made it useless, since the stages weren't built against it anyway. Via that logic (don't change it lest it negates a release), we would never be able to do changes, or would be forced to do changes strictly whenever y'all are doing a new release. Profiles aren't bound to the releases, despite how people may view it and/or the current profile maitnainer's usage of 'em. My point is pretty simple, why should we spend a bunch of time maintaining something that is designed from the start to be customized, and most likely won't even be used anyway? That's the issue; the profiles in their current form are customizable only in the ability to negate a collection of flags. Negating the whole beast is another story due to the desktop cruft being shoved into the arch subprofiles. I would much rather stick with the 2005.1 profile meaning what we used to build 2005.1 than having it mean some variation of 2005.1 is below here and using this profile is minimal and likely won't do what you expect. Again, releases may be bound by available profiles, but available profiles are not bound by available releases. Aside from that, the comments about variations/minimal/not doing what you expect, what do you think USE=-* user's actual desired flags accomplishes? Profile customization occurs, /etc/portage/profiles exists for this reason; the 2005.1 profile (fex) is probably *rarely* ran exactly as y'all have it specified considering we do have user level use flags, tweaking the hell out of '05.1. Aside from mild disagreement on views, as was stated in previous emails, multiple inheritance I tend to think is required to minimize the work for y'all; what I want you guys to do (or I'll do myself) is chunk the suckers up so people after a minimal base for running it themselves, or building up their own subprofile can do so. Not after jamming maintenance nightmares on you, which without multiple inheritance, might be a bit. ~harring pgpnO9KjjXNG9.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Mon, Aug 29, 2005 at 01:27:34PM -0400, Chris Gianelloni wrote: This could still be done under profiles. Personally, I like the idea of something more like this: project/os/arch/version for profiles This would give us something like this: default/linux/x86/2006.0 default/freebsd/alpha/2006.0 hardened/linux/amd64/2006.0/2.4 hardened/freebsd/x86/2006.0 uclibc/linux/mips/2006.0/cobalt server/linux/x86/2006.0 I like... That's pretty much what I'm aiming for; not after forcing *you* to do server/etc, just would prefer to see it structured so that others can do so. That said, initial email was worded a bit strongly, so pardon ;) Two scenarios for how this will result in visible issues for people- 1) CVS users, aka, devs. Devs *should* be running latest portage, which would know about the shift. If they're running an older portage version and aren't willing to upgrade, they tag the symlinks themselves. It's a minor annoyance frankly; assuming they read -dev (like they're suppossed to :P ), they'll know in advance it's coming. Many devs use the latest stable versions of packages rather than testing versions. I tend to find this to be a good thing as there are often bugs in particular combinations of package versions that aren't necessarily spotted when running all ~arch. Also, devs are not required to read or even be subscribed to -dev. Agreed. Implicit in all this is that I'm going to have to make a bit of noise (and probably attempt and get it shoved out via gwn) prior to doing it, so that I don't have ~100 devs who didn't hear the news looking in my direction. ~harring pgplt9NvIQa2x.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Mon, Aug 29, 2005 at 05:48:20PM -0400, Chris Gianelloni wrote: What other changes are you guys thinking of regarding profiles? That would be Marius's department. I'm not willing (personally) to look at revamping profiles till rewrite is finished. At that point, new profile's should be able to be just plugged in; I don't care to bite off any more then I already have ;) Offhand, I'd expect the removal of package filtering in the packages files (package.mask provides this already), probably a bit of renaming of packages also. Why? Packages is vague. Stupid reason to change it I realize, but packages makes sense in a single set, 'system' set view. Rearrange it so that packages isn't auto assumed to be system, stick it in a subdir fex, and you would give profiles the capability to arbitrarily define their own sets. Aside from that, the parent implementation could stand a tweak or two. Further, assuming metapkg goes through, virtual is obsoleted. The inclusion of GRP_STAGE23_USE also bugs me a bit; yes it works right now, but what happens when you need to push more info in? Seems like it should be contained on it's own. Either way, just a couple of things off the top of my head. My main push for it is cleanup for stand alone repositories, and ensuring anything people attempt with profiles doesn't have side effects on the raw repositories metadata. ~harring pgpYLVPpS4XfW.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, Aug 29, 2005 at 05:43:35PM -0400, Chris Gianelloni wrote: snip Re: not shoving work onto you, complicating your job, etc, I agree, and actually is what I was getting at in the badly worded section below My point is pretty simple, why should we spend a bunch of time maintaining something that is designed from the start to be customized, and most likely won't even be used anyway? That's the issue; the profiles in their current form are customizable only in the ability to negate a collection of flags. Negating the whole beast is another story due to the desktop cruft being shoved into the arch subprofiles. Sorry, but this didn't make a bit of sense to me. Perhaps you could reword it? Basically stating that if I want the minimal 2005.1 x86 profile to build my own server profile off of, I can't really use the existing default-linux/x86/2005.1 ; Why? Mainly due to the fact that I would be forced to reverse a *lot* of stuff, use flags mainly, to get it back down to a minimal profile. That's what I mean by lack of customization; it can be done, but it's not optimal, vs say inheriting a base default/x86/2005.1 that holds just system defaults (pam, cflags, etc). If I were to implement a server profile from existing, I'd probably tag in -* to the use, and add the use flags I explicitly want; that's not really the best way to use the profiles inheritance capabilities though :) Profile customization occurs, /etc/portage/profiles exists for this reason; the 2005.1 profile (fex) is probably *rarely* ran exactly as y'all have it specified considering we do have user level use flags, tweaking the hell out of '05.1. You would be surprised at the number of people that use GRP and rarely, if ever, change their USE flags. I wish I had numbers, but I don't. Anyway, the default set of USE flags seems to be a pretty perfect mix for most people. It gives packages that work as expected, and is geared toward a desktop system. Without any more specific examples of what you're trying to point out, I'm just not seeing it. Key thing to note, neither of us have figures :) Beyond that, I'm not after castrating the defaults that exist, I'm after sticking a level of indirection, a subprofile into the releng profile inheritance chain so that if I *want* a minimal profile (as you use), I can get it without having to resort to -* and tracking all of the changes myself. It's a time saving effort; add multiple inheritance in, and it's easy to do (win/win). Aside from mild disagreement on views, as was stated in previous emails, multiple inheritance I tend to think is required to minimize the work for y'all; what I want you guys to do (or I'll do myself) is chunk the suckers up so people after a minimal base for running it themselves, or building up their own subprofile can do so. Not after jamming maintenance nightmares on you, which without multiple inheritance, might be a bit. I know that I won't be spending *my* time making any profile other than the defaults used for building the release. Anyone is welcome to build profiles for anything else that they might want, but since the release team doesn't use it, we shouldn't be forced to waste our time on it. Agreed, although I'd posit that when/if multiple inheritance is added, y'all take advantage of it (break up the settings into base and desktop) so that others can use your base work instead of reinventing the wheel. ~harring pgpfFtin4sgb9.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Sun, Aug 28, 2005 at 02:31:24AM -0700, Zac Medico wrote:
Brian Harring wrote:
Please test this out; if you want to test the EAPI checking, tag
EAPI=1 into an ebuild, and try making emerge bail.
I needed to patch ebuild.sh so that EAPI would be parsed. It bails out
properly now.
Crud, didn't include that file.
Should be echo `echo ${EAPI:-0}` actually
~harring
pgpCH7bAJN24M.pgp
Description: PGP signature
[gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Note, sending to dev only, not cc'ing core; the inital -core post was to make sure those who aren't watching dev ml see the email (annoying, but it's an old habit I've yet to kick despite needing to). On Sat, Aug 27, 2005 at 04:48:26AM -0500, Donnie Berkholz wrote: Brian Harring wrote: I don't recall having kde/gtk crap turned on by default when I first showed up. Maybe I'm missing something; regardless, the defaults (which should be minimal from my standpoint) are anything but. I think you recall wrong, then. The default USE flags have been set so that the majority of systems will work properly without modifications, not so that they're the minimal set. Already stated that it's entirely possible my memory is whacked, that said my point still stands. The purpose of being able to negate USE flags in lower cascaded profiles is pointless if each level is the minimum. I think it makes more sense to have each level be a reasonable default that most people would prefer, then have weird exceptions subtract it. Note I'm not advocating every level of the profile be bare minimal, with the end nodes having tons jammed into it; I'm advocating exactly what you're stating. Chunk the sucker up, shifting stuff around just the same as you would if you were designing base classes to be inherited. The thing to note is that if you're relying on negation, it's going to bite you in the ass without efforts. A server subprofile pulling from a parent that holds desktop cruft will be forced to either A) reinvent the wheel (maintain their own USE list), as a sizable chunk of users do via -* usage B) or very carefully watch people screwing around with the parent, tagging in a new desktop USE var, and adding the matching negation. What I'm advocating is that the '05 profile (fex) tag in the defaults for that profile release, desktop/server agnostic, *system* defaults, eg toolchain, pam, nptl, etc. The subprofile the user chooses (the desktop or server target) building upon those base settngs. Multiple inherits for profiles is the main reason I'm not pushing on this; shifting desktop cruft out of the bases (my definition of base mind you) requires pulling from (fex) x86/2005.1 + desktop/2005.1 . My 2 cents at least. ~harring pgp3jPtVK3rmH.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote: On 27/8/2005 10:42:25, Brian Harring ([EMAIL PROTECTED]) wrote: Hola all. Straight to the point, I'm proposing that the following files- arch.list categories use.desc use.local.desc package.mask updates be moved out of the profiles directory in the tree Not sure about package.mask. I thought that was part of the profile, as different profiles might package.mask separately. I know I use it in /etc/profile to postpone updates. Rough filtering stack- profiles/package.mask /etc/make.profile/package.mask (incremental through subprofiles) users package.mask, and users package.unmask Ordered it in that fashion to show that it's effectively repository filtering, profile filtering, user filtering; if you view it as seperate entities with filters stacked up (how the rewrite implements it), package.mask being repository metadata becomes clear. Basically, think of it this way; what files/data *must* stay with a repository? If I'm using (say) gentopia ebuilds, the p.mask they use is specific to _their_ repository; my official gentoo repository should not be p.mask'ing there stuff, it should only affect itself, and any repository that is slaved to it (overlays, which aren't stand alone). At least that's what I think :) ~harring pgpDVd29qJQ0C.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 01:32:33PM +0200, Fernando J. Pereda wrote: On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote: Not sure about package.mask. I thought that was part of the profile, as different profiles might package.mask separately. I know I use it in /etc/profile to postpone updates. In fact the arch teams use it to mask packages that won't work on a particular profile/arch. If package.mask is removed from the profiles directory does it mean we won't be able to do that anymore ? You're masking occurs within the profile itself, not globally. Global masking usually is for introduction of new ebuilds that need testing and shouldn't be hit by normal arch testers (portage early release candidates for example); if you're blocking valgrind on arm (fex), you *should* be blocking it in profiles/default-linux/arm, not profiles/package.mask ;) If it's profile specified files, relax, not targeted :). Strictly after getting the global data out of there, and into a directory reflecting that data's actual role within the repository, and makes sense in a more flexible, non single $PORTDIR+$PORTDIR_OVERlAY environment. Aside from that, see my other email re: the seperate levels of filtering :) ~harring pgpDGxBzbNfMb.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 03:29:32PM +0200, Kevin F. Quinn wrote: On 27/8/2005 13:34:15, Brian Harring ([EMAIL PROTECTED]) wrote: Rough filtering stack- profiles/package.mask /etc/make.profile/package.mask (incremental through subprofiles) users package.mask, and users package.unmask Ordered it in that fashion to show that it's effectively repository filtering, profile filtering, user filtering; if you view it as seperate entities with filters stacked up (how the rewrite implements it), package.mask being repository metadata becomes clear. Would it make sense to simply relocate the global package.mask and package.unmask to the base profile from which all profiles derive (haven't checked that they all do)? No global unmask; What you're proposing is actually exactly what I'm against; if I choose to use my own profile that's not bound to the tree's profile, I should still have my repository masked by the global profile.mask that's in it. Shifting it to base profile forces me to either copy the package.mask (or symlink it, which isn't possible in remote), or do without it (bad, able to hit packages with security holes and stuff that shouldn't be used). repository package.mask is a seperate filter from profile filter.mask, basically. Users's data could be placed in the users profile at /etc/portage/profile instead of /etc/portage, and the concept of global package mask/unmask as repository metadata would go away. global p.mask is a seperate thing from profile specific p.mask, which is the basis of me wanting it moved out of there :) ~harring pgpUK00XA3PyJ.pgp Description: PGP signature
Re: [gentoo-dev] EBUILD_FORMAT support
Pardon the delay, been putting this one off since it's going to be a fun one to address, and will be a bit long :) On Thu, Aug 25, 2005 at 12:34:00PM +0200, Paul de Vrieze wrote: What I mean is compatibility with current portage versions. Current versions do not understand EAPI. There would be a good chance that they could choke on packages with all kinds of new features, even in the sync phase. A different extension would ensure that those portage versions would still work (crippled) on a new tree. Of course such an extension change should only be done once. Once the API versions are available this is not an issue. General portage stance towards EAPI is unset EAPI == 0 (current stable ebuild format); if EAPI then portage internal EAPI, unable to merge, which should be able to be detected during buildplan. Current portage doesn't know about EAPI; boned in that respect I'll admit, but it's the case for all new features rolled out- three options for dealing with this 1) Usual method, deploy support, N months later use support. 2) tweak stable so it's aware and can complain. Still requires people to upgrade, just makes it so that they're not forced into upgrading to 3.x; this is mainly a benefit for those who may don't care to try the first few releases of 3.x when it hits (akin to people dodging the first release or two of a gcc release). Worth noting that one rather visibile aspect of EAPI=1 is that (assuming the council votes on it, and yay's it) glep33 *will* result in current eclasses being effectively abandoned w/in the N months after an EAPI capable portage is released. Sound kind of bad, but people will have to upgrade for the capabilities. If EAPI was pegged into portage/ebuilds already it wouldn't be an issue, issues could be detected prior. Unfortunately it's not, and introduction of it (and use of it) is going to involve a few road bumps. Plus side, once it's in, portage *will* know if the ebuild is incompatible with the pythonic/bash ebuild code, and portage/the UI can act accordingly. Meanwhile, the changes that are being pushed into EAPI are addition of configure phase (broken out from compile), elib addition, and eclass2 support (same beast, different rules due to env save/restoration). The potential for horkage on sync'ing isn't there due to the fact that's purely python side; ebuild*sh doesn't play into it. Re: regen, issue isn't really there either; if you try and merge an eapi=0 on a non eapi aware portage, it works, same as it did before. If you try to merge an eapi=1 ebuild you hit either an issue with inherit, or a bail immediately in src_compile, due to the fact eapi=1 ebuilds will seperate configure out from compile (eapi=0 portage won't know to call it; no configure == failed compile). That said, there also quite likely is a change coming down the pipe to the tree's cache; the change will shift the rsync'd metadata cache over to a key/val based cache. Why oh why, yet another cache change? Simple. The change moves away from list based format to key:value pairs; in short it's a change that once made, means keys can be added to the cache from that point on without causing cache complaints on sync'ing. Last cache breakage, I swear :P EAPI addition being the next key tagged in; stable (not surprising) needs to be released with a version capable of reading both old and new format; once that's done, time for the usual yo, upgrade people, something's coming down the line. Same version that supports old and new cache format can also include rudimentary eapi awareness. At least that's what I'm thinking. It's roughly inline with the previous forced cache breakages, just in this case slipping in some extra support in the process. Notices obviously would go out prior to moving on this also, along with a good chunk of waiting. ps. I would also suggest requiring that EAPI can be retrieved by a simple line by line parsing without using bash. (This allows for changing the parsing system) No, that yanks EAPI setting away from eclasses. If the eclasses follow similar rules that would be easilly parseable. (taking inherit ...) into account is easy as long as the inherit line is on one line of it's own. (unconditionally) These rules that would allready be followed out of style reasons would make various kinds of parsers able to parse them. while it's insane, people *can* use indirection (eg inherit $var) for inherit's as long as it's deterministic, always the same inherit call for that ebuild's data. Don't see a good reason to ixnay that, which means we'd have to parse the whole enchilada, eclasses and the ebuild. Effectively, raiding a single var out wouldn't fly; eclasses could override an ebuild's eapi setting for example, just like any other metadata key (imo). A *true* format change, moving away from bash for example or moving to an executing design of ebuilds would require an
Re: [gentoo-dev] [RFC] EAPI
On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote: On the EAPI subject Brian just brought back, I had this idea that we could use the same approch XML took with HTML. The ebuild could define which EAPI to use, but instead beiing a version, the EAPI would be an ebuild API definition. The equivalent to the XML's dtd. The ebuild could point to a directory named $PORTDIR/eapi/eapi-name/ which would contain a python script named eapi-name.py. If not already loaded, that plugable eapi would be loaded before processing the ebuild. That way, there is no outdated ebuild format. There is just a default format which is the actual format. It could also be an XML defining the ebuild's build sequence and other particularities a group of ebuild could have. Few questions; A) what does xml bring to the table explicitly that is needed? remember portage doesn't have a hard dep on xml parsing libs yet, this would add it (livecd/stage* potentially needing adjustment as a result). B) EAPI is pretty much bash env template switching; xml/python plugins don't help in that respect, although a python plugin for that eapi level may be added at some point (right now it's not required for the eapi v0/v1 python side components). I am worried, long term mind you, in tracking the differences between eapi levels and keeping the code clean. My thought for way down the line when an eapi level has long since gone unused is to break it out of portage and into it's own package as a plugin. Specifics of it haven't yet gotten to, mainly because it's not worth sweating over till rewrite is usable (priorities), but that's the long term intention for EAPI. Beyond that, the question of what needs to be tracked outside of python/bash code (what would be stuck in the suggested xml) should also be clarified, since I'm not seeing what all would be jammed in there. ~harring pgprFuJJx6RR1.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI
On Fri, Aug 26, 2005 at 03:02:13PM -0700, Drake Wyrm wrote: Brian Harring [EMAIL PROTECTED] wrote: B) EAPI is pretty much bash env template switching [snip] Perhaps the EAPI handling could be implemented using eclasses, rather than something in the deep, dark, python-based internals. Effectively the implementation is essentially an eclass, but won't wind up in $PORTDIR/eclass due to the fact it's also slightly bound to python side. For example, the ebuild build operation class knows not to command the ebuild processor to execute the configure phase for eapi0, 'coz that hook doesn't exist. For eap0, it commands it. That's about the extent of python side awareness at this point, beyond checking min/max eapi support. ~harring pgp32nn4HxHSq.pgp Description: PGP signature
Re: [gentoo-dev] future restrictions to DISTDIR access from the ebuild env
On Thu, Aug 25, 2005 at 12:05:11PM +0200, Paul de Vrieze wrote: Why not create that directory in the /var/tmp/portage/package/ directory. It would also safeguard against packages using files that they did not request. Maybe in the future a similar thing could be done for patches (when ebuilds finally get to specify which files from the files dir they use) using $PORTAGE_TMPDIR/portage/$CATEGORY/$P/distdir atm Note the additional $CATEGORY dir; unless people scream, it's wise from where I'm sitting- it avoids potential $PORTAGE_BUILDDIR conflicts. Yes they're unlikely, but why allow for it? Re: patches, would be game, just not sure of a clean way how. And for the truly paranoid, had thought about transfering $FILESDIR in during verification. That's a bit much for local trees, but for remote tree's $FILESDIR will be $PORTDIR/$CATEGORY/$P/files simply because a place is needed to slap the files on the local fs. ~harring pgpKfa528K9cr.pgp Description: PGP signature
Re: [gentoo-dev] Package version requiring sse
On Thu, Aug 25, 2005 at 01:41:00PM +0200, Paul de Vrieze wrote: On Wednesday 24 August 2005 15:23, Martin Schlemmer wrote: Same thing (and probably better option) if you put it in pkg_setup() ... Isn't pkg_setup run too when just building a binary package (-B) (then the check shouldn't be performed), and just before installing a binary package? Yep, something that's rather unclean. Reinitializing the env for the local box I have no issue with, I just dislike re-running pkg_setup which also set's up vars for building. Alternatives welcome mind you... ~harring pgp4Szt4FBUsM.pgp Description: PGP signature
[gentoo-dev] crap use flags in the profiles
Hola all. Out of curiousity, since for once my portage installation is *not* filtering out all flags but my own, I'm wondering why it is that the system default now holds a lot of use flags that aren't really related to the system set of packages. See, from my standpoint cascaded profiles exist for the sake of being able to build up chunks, and merge them together. If you want a desktop profile, hey, easy, just point it at the default, and import that. If you want a server profile that doesn't have the crap 101 use flags that are defaulted, you just define a profile there. The common point between the two being that you depend on a minimal, this is the base profile that is the common points, and overload what you need to in the specialized profile. Iow, you jam all of the crap use flags into a desktop profile, rather then forcing people to do -* So, fex, the following flags are rather desktop specific- alsa arts avi bitmap-fonts cups eds emboss (why the hell is European Molecular Biology Open Software Suite a profile default? Seems extremely specialized) encode fortran foomaticdb gnome gstreamer gtk gtk2 imlib kde mad mikmod motif mp3 mpeg ogg oggvorbis oss png qt quicktime sdl spell truetype truetype-fonts type1-fonts vorbis xml2 xmms That's pretty much the entire list of flags in the defaults. Again, returning to the USE=-* arguement, yes, they can go that route. It's also kind of a crappy arguement dodging out of the fact that progressive bloat going into what is effectively a base release profile, when subprofiles would be better suited. You use the capabilities cascaded profiles give you, and you can serve both camps; those who want bloat, those who don't. Question is why aren't we? Yes work is required, but everything requires work- is there some stumbling block that makes the work involved excessive? Personally, I run with -* not due to filtering out profile crap, but for filtering out autouse; I'm a bit disgusted by what the -* has been protecting me from. In bug 93067, it's described that our default has always been to aim for desktop; well, depends on your definition of desktop. I don't recall having kde/gtk crap turned on by default when I first showed up. Maybe I'm missing something; regardless, the defaults (which should be minimal from my standpoint) are anything but. So... again. What is holding us back from using existing capabilities to seperate this? If it's not perfectly clean doing it, what do you require to make it easy/clean to do so? Granted this phrase has been beat to fricking death, but we are about choice. Again, yes, -* is a choice, it's also a rather nasty choice since the user must watch the profile's themselves and duplicate the use flags from there if they want the 'true' defaults. That's shoving work off onto users when an alternative approach (subprofiles) could handle it globally. So yeah, subprofiles, reasons why not? My slightly flamey 2 cents ~harring pgpMmEunbZjw9.pgp Description: PGP signature
Re: [gentoo-dev] crap use flags in the profiles
On Wed, Aug 24, 2005 at 08:50:58PM -0400, Mike Frysinger wrote: On Wednesday 24 August 2005 08:04 pm, Brian Harring wrote: Again, returning to the USE=-* arguement, yes, they can go that route. It's also kind of a crappy arguement dodging out of the fact that progressive bloat going into what is effectively a base release profile, when subprofiles would be better suited. not sure what you mean by 'progressive bloat' ... most of those flags have been there since before i was a dev (so like before the 1.2 release) the default profile has always been a 'desktop' target and really i think that's OK by me Reasons against sticking a level of indirection in? More then willing to assume I've been a tool and missed it, but with cascaded profiles there really isn't a good arguement against tagging a level in so that anyone after it can just use minimal, or derive a server profile off of it. ~harring pgpu7928lrHS0.pgp Description: PGP signature
[gentoo-dev] future restrictions to DISTDIR access from the ebuild env
Hola all. robbat2 made the suggestion, and after a bit of playing I think it's best- in short, to support multiple DISTDIR's, we need either intelligent querying of portage from bash side as to a files true location, or a directory full of symlinks pointing at the ebuild's stated files. Latter is easiest imo, and a bit cleaner for a dev to be able to look at it and see why things are breaking; upshot, adding this indirection allows portage (with sane fetcher(s)) to do N DISTDIR, and it also causes any ebuild that has unstated SRC_URI deps to bail. The forced bail pretty much makes it so that an ebuild dev can't easily screw up, they hit the unpack failure rather then a commit and a user hitting it. If you've got issues with it, give a yell; just added this in the rewrite. ~harring pgpdeyhzVW7mN.pgp Description: PGP signature
[gentoo-dev] portage rewrite snapshot (was RFC - Gentoo on the Lab)
On Tue, Aug 23, 2005 at 06:58:53PM -0400, Kristian Benoit wrote: Yeah, I'd really like having a snapshot, even if I'd prefer having cvs/svn access. You can send me it by mail or make it available somewhere. Pardon the delay, wanted to iron out building code before pushing the snapshot up- it's available at http://dev.gentoo.org/~ferringb/new-08-25-05.tar.bz2 anonsvn is in the air, but in the interim I'll be doing snapshot's as stuff comes in. /me notes again, that it is not usable yet. You can build packages with it, but the classes for merge operations aren't in place, meaning no merge. Bugs probably exist up the ying yang also; if you want to hack on it, then by all means go for it, otherwise kindly wait (general disclaimer that one). ~harring pgpYOTVoBMFSi.pgp Description: PGP signature
Re: [gentoo-dev] How to tell 2.1.8 20030601
On Tue, Aug 23, 2005 at 08:23:24AM +0200, Dirk Heinrichs wrote: Hi, I have written an ebuild for pam_krb5, based on the version found in fedora, since the one from sourceforge which is currently in portage is way outdated. However, even after reading all the ebuild docs, I can't figure out how to tell portage that version 2.1.8 is newer than 20030601. The only way I could convince portage to replace pam_krb5-20030601-r1 with pam_krb5-2.1.8 was to mask the former. There's no way for portage to know that 20030601 is newer then 2.1.8, without knowing when 2.1.8 was released (that metadata ain't going to be jammed in either) So... boned. :) ~harring pgpOFjKpCFkiD.pgp Description: PGP signature
Re: [gentoo-dev] Gstreamer + Use Flags
On Tue, Aug 23, 2005 at 09:21:50AM +0200, Fabian Zeindl wrote: Since nobody except Diego replied on my mail a week ago: Is there another way besides filing bugs and mailing the list to make a proposal which gets investigated? I think many users are concerned about that gstreamer oddness, and I didn't find one good reason while reading through bugzilla of not doing this the way I proposed. As stated in 100872, any solution involving centralizing the use flags on gstreamer requires use deps. Can't centralize the use flags on gstreamer till they're available, without doing something QA has every right to wedgie you for (build_with_use die's in pkg_setup). ~harring pgpBrRxnroAGV.pgp Description: PGP signature
Re: [gentoo-dev] EBUILD_FORMAT support
On Tue, Aug 23, 2005 at 03:20:16PM +0200, Paul de Vrieze wrote: To allow for this to work with current portage versions, perhaps it would be an option to introduce a new extension for .ebuild scripts that use it's functionality. That would allow all non-EAPI aware portage versions to automatically ignore ebuilds that use this. not much for .ebuild? in the tree, personally. Why? Cause portage *should not* ignore those ebuilds. If the user wants to merge something that is a later ebuild api then they have, at least portage chucks an exception that the UI can wrap into upgrade portage. With what you're proposing, we instead get bugs about portage missing packages. ps. I would also suggest requiring that EAPI can be retrieved by a simple line by line parsing without using bash. (This allows for changing the parsing system) No, that's yanks EAPI setting away from eclasses. Only time this would be required is if we move away from bash; if that occurs, then I'd think a new extension would be required. As is, shifting the 'template' loaded for an ebuild can be done in ebd's init_environ easy enough, so no reason to add the extra restrictions/changes. My 2 cents, at least ;) ~harring pgpcTll4VxAEM.pgp Description: PGP signature
Re: [gentoo-dev] RFC - Gentoo on the Lab
On Tue, Aug 23, 2005 at 12:25:03PM -0400, Kristian Benoit wrote: On Mon, 2005-08-22 at 15:39 -0500, Brian Harring wrote: That and help would always be welcome :P Then where do I find the code (I'm an official dev yet, so I only have access to what's in the mirrors and the patchs on mailing lists) Timing mildy sucks; just switched over to svn, making our anoncvs access pointless for the rewrite. So... after anon svn to replace loss of anoncvs provided by carpaski. Meantime, anyone who wants snapshots can scream at me and I'll post them- anon svn if it is agreed to be implemented infra wise, once it's up the info will be posted in gentoo-portage-dev ml, and tagged into /topic in irc (the norms). ~harring pgp1AfM7QPS5I.pgp Description: PGP signature
Re: [gentoo-dev] RFC - Gentoo on the Lab
On Tue, Aug 23, 2005 at 12:25:03PM -0400, Kristian Benoit wrote: On Mon, 2005-08-22 at 15:39 -0500, Brian Harring wrote: That and help would always be welcome :P Then where do I find the code (I'm an official dev yet, so I only have access to what's in the mirrors and the patchs on mailing lists) If you're after a snapshot, give a yell; right now still waiting for svn crap to straighten out (mainly for the rewrite to be moved fully to svn), but once done I can point you at wherever I dump it in my devspace till anonsvn is up. No clue on eta of anonsvn, that's infra's thing unfortunately. ~harring pgpFq2SET6KV1.pgp Description: PGP signature
Re: [gentoo-dev] RFC - Gentoo on the Lab
Lot of text left inline, pardon, just scroll and deal with it :P On Tue, Aug 23, 2005 at 12:28:08PM -0400, Kristian Benoit wrote: Here is my recent communication with Pieter: On Sat, 2005-08-13 at 21:59 +0200, Pieter Van den Abeele wrote: On 13 Aug 2005, at 19:16, Kristian Benoit wrote: I've heard that you might be the last to know something about portage-ng. What's the actual status, Here's what I've done so far: I've build upon Andreas' Zeller idea of using Smolka's feature logic for software configuration management. Zeller's approach was ok for determining consistency/inconsistency of software configurations. In his phd thesis he described the algorithm involved and discussed time complexity (which goes to NP if you allow for quantification). My impression after implementing his idea was that for automated construction there were a few things that were lacking, and some things were incorrect. I revisited Zellers feature logic, and ended up with a clean implementation of a declarative language which has some very desirable properties for automated software construction. I'd say my approach is closer to the spirit of Smolka's feature logic than Zellers approach. My non-destructive feature unification has a worst case time complexity of O(n x m) where n is the length of the feature term describing your system, and m is the length of the feature term describing the component to be added. In practice performance is very good. An emerge --vp --emptytree kde with the regular portage takes about 55 seconds on my Open Desktop Workstation and produces a list of 200 packages. A similar action using my implementation: = Total time: 14.55 seconds = Predicate Box Entries =Calls+Redos Time = vunify/4341,900 = 341,900+072.6% $garbage_collect/1 326 = 326+013.6% lists:append/3 684,320 = 684,320+0 4.0% genterm/2 520 = 520+0 3.9% hunify/4520 = 520+0 3.3% is/2342,420 = 342,420+0 1.8% /2 342,160 = 342,160+0 0.8% buildsystem/2 1 =1+0 0.0% val/3 5,200 =5,200+0 0.0% unify/3 260 = 260+0 0.0% % 9,531,861 inferences, 13.96 CPU in 14.55 seconds (96% CPU, 682798 Lips) Stating it as nicely as possible, without knowing what that's doing, stats can be construed several ways; faster backend access (both vdb and ebuild/cache), dodging/caching virtuals, etc; language implementation is a point of curiousity also. Faster implementation doesn't surprise me- stable portage is fricking *absolutely* retarded about caching, parsing of deps and cpvs, loading of profile, etc. Either way, interest remains in seeing it :) The search space is kept as small as possible because I've introduced lazy feature evaluation and both multi valued and open features. Those concepts are missing in Zellers approach. Comparing current portage and my implementation performance-wise is difficult. In general mine is faster, but current portage doesn't use sql either. What is for sure is that mine allows you to express various constraints. You can prevent a dependency from being built with a specific use flag. My implementation automatically solves 'blockers'. Circular dependencies are also solved correctly. For instance, if you want to install unixodbc with the qt use flag enabled and you want to install qt wit the unixodbc use flag enabled, my portage knows that it needs to: emerge unixodbc without qt emerge qt with unixodbc remerge unixodbc with qt support So it makes revdep-rebuild unnecessary basically. revdep-rebuild is still necessary, regardless of use deps or full state graphs- anyone doubting that should take a look at the breakage that has occured whenever mysql/ssl have decided to change their soname while maintaining compatibility. Need a bincompat metadata attribute to kill off revdep-rebuild. Once I was done implementing this new declarative language in which for instance ebuild concepts can be easily expressed (but also rpm, deb, fink, darwinports). This sounds a lot like my restriction subsystem in the rewrite (code's available to anyone after it). With the restriction setup, anyone who wants it could just plugin a different repo/pkg plugin, and have deps based on sonames fex; granted anyone doing
Re: [gentoo-dev] stripping implementation in portage
First, sidenote (mild ot to this thread also), pardon the dupe posts, thick fingered typing dumping an old message :) On Tue, Aug 23, 2005 at 01:34:33PM -0400, Olivier Crete wrote: On Tue, 2005-23-08 at 11:16 +0200, Paul de Vrieze wrote: As an aside to this. Does anyone know how debug information can be changed to have a different basedir. My idea was to create a custom strip wrapper that would create external debugging files (like now possible with gdb/binutils) and point them to a location in /usr/src/packagenameplusversion. For that it would be necessary to in some way hack the source location in the debug information. There is already a patch [1] in bugzilla that does that.. And in bonus to keeping the debug files (currently in libpath/.debug/libname.so.dbg but that can be changed) . It can also keep the source files in /usr/src/debug so they can loaded by gdb (pretty useful when debugging into libraries). It creates 3 new features, keepdebug, keepdebugbin and keepsources Would rather implement those as filters as described above; short version is that features is chunked up in the rewrite, so it's options on the component you're configuring moreso. That said, still will map from old make.* to new format (on the fly, no forced config upgrades), but I'd rather see it implemented as I've proposed. Reasoning is that if you build with debugging crap on, you've got maximal flexibility in your choice of what your binpkgs/vdb winds up with. Thoughts/yay/nays? ~harring pgpuI2Rt4hbCP.pgp Description: PGP signature
Re: [gentoo-dev] stripping implementation in portage
On Tue, Aug 23, 2005 at 01:58:46PM -0400, Olivier Crete wrote:
I havent looked at your new implementation (does it exist).. but yea
what you wrote seems to make sense... except that I keep the source code
too.. so it would bloat binary packages.. I think it should be done
before the packages are made.. or maybe use separate debug and have
separate debug packages like RedHat does.
Your choice of what goes into the binpkg is just that, your choice,
just the same as your choice of what ultimately hits the livefs.
Bit of a shift in terms of how things are designed; repositories are
base objects, things like package.* filtering and changing
(package.use) is implemented as wrappers of the repo. Wrapper base is
implemented, as is the filtering wrappers; for what's discussed above,
just need to design an appropriate contents filter.
Re: does it exist, yes (in cvs, and now living in svn), better
question, is it usable yet, no; core was yanked, rebuilding it. This
is a sizable chunk of why feature requests are on hold- either more
crap gets duct taped into portage, or design is corrected so
features/additions/tweaks/whatever is easier to do. Long term
maintenance/extensibility vs short term gain is the crux of it.
What you're after can be pulled off, and the specification of what
type of stripping to do can be left to the user's config for that repo;
intention is to allow you to strip sources for binpkgs fex, while not
stripping sources for livefs merge.
Just a question of how you define your config; the restriction/depends
bit referenced in the other thread relates to this, you define the
classes needed and define your config to use them, using alt. formats
should be possible (exception: OE format I don't see any way to
support of what I know).
So... the sources concern is moot. Hell, via the wrapper approach if you
wanted you would be able to define your own wrapper that splits a pkg
into chunks, or have the repo do it. Don't really care what you do,
just care correcting underlying issues, and having the remaining beast
flexible so people can do whatever crazy crap they want instead of
directly hacking portage innards.
Sidenote, wrapper approach is how install_mask/no{man,info,doc} will
be defined, rather then jamming crap into the core. Define it as
seperate chunks, and you can arbitrarily arrange it, doing whatever
the hell you want.
~harring
pgpLZIfXX01Jd.pgp
Description: PGP signature
Re: [gentoo-dev] download problem in ebuild
On Wed, Aug 24, 2005 at 12:11:19PM +1200, Nick Rout wrote:
On Tue, 23 Aug 2005 04:41:49 +0200
Marius Mauch wrote:
DOWNLOAD_CMD=wget http://laby.toybox.de/download15/ -O
laby_$(P).tar.gz
Nope. You have three options:
a) bug upstream to fix that crap
b) use RESTRICT=fetch
c) assuming the license permits it, repackage it
Marius
So am I being told that you can't change stuff from make.conf per ebuild?
That would fix it I think.
FETCHCOMMAND=${FETCHCOMMAND} -O laby.${PV}
Can't vary fetchcommand per pkg, since it's a completely seperate
thing from the ebuild env.
~harring
pgpiwpyxLiE49.pgp
Description: PGP signature
Re: [gentoo-dev] download problem in ebuild
On Wed, Aug 24, 2005 at 12:34:41PM +1200, Nick Rout wrote: Thanks to all of you, thats now very clear. The message i have is that it will work, but its not allowed. Wrong interpretation- it won't work within an ebuild. It requires exteneral user intervention to make the ebuild work, *every* time. Won't work == not allowed in this case, cause it... won't work for ebuilds... Etc. ~harring pgpwi44u6wx85.pgp Description: PGP signature
Re: [gentoo-dev] RFC - Gentoo on the Lab
On Mon, Aug 22, 2005 at 01:49:14PM -0400, Kristian Benoit wrote: On Mon, 2005-08-22 at 16:38 +0200, Marius Mauch wrote: Anyway, I hope you realize that your project doesn't only involve hacking on portage, but rewriting almost all of it for the client part. Actually I'd rather suggest you start from scratch I do agree with that, portage probably need a rewrite/better modularization anyway. There is/was a project called portage-ng () you might want to have a look at. I did a little in that direction recently, and it seems that there is not too many people working on it since drobbins left, but you can contact Pieter ([EMAIL PROTECTED]). I might get on that too at some point in the future too. Portage-ng never resulted in anything tangible (read: code), further the doc wasn't really useful for anything then jotting down what's desired. Unless something's changed, that doc should've been yanked down. She's dead, jim. Regarding modularization of portage, it requires that, but fundamentally it requires a rewrite of the core; there is no internal package abstraction, repository abstraction, hell, even a clean config abstraction (let alone cache abstraction). The 2.1 code that was pushed out for inspection addresses the cache issue mostly, and modularization as much as possible. Everything else falls to the rewrite which is underway- I'd suggest contacting portage devs, since what you're after is pretty much what's been designed to allow for, without requiring hacks to portage- just would be plugins. That and help would always be welcome :P ~harring pgpTyRVwDeVAP.pgp Description: PGP signature
[gentoo-dev] stripping implementation in portage
Hola all. Short version, the nostrip feature is a bit funky as an option. What I'm after is effectively building all packages *with* debugging information as default, and leaving it up to the repository you're merging the package to, to decide on stripping or not. IOW, if you prefer stripped binaries on your livefs, the stripping occurs while merging to the livefs- this leaves you the option of having binpkgs that *do* carry non-stripped binaries/libs. Situation can be reversed also, for the embedded crowd. Downside, for people who flat out want stripping across the board, it's a bit more flipping it on, although that's addressed via inherit support within the underlying config (just take my word on that one :) Also involves a bit more logic, but that's just implementation voodoo. So... thoughts? I'd be particularly curious about any package where this wouldn't be viable. Aside from that, cc'ing both lists, would prefer the discussion on dev since the implementation can go either way; preference of if that flexibility is desired or not is a user thing, so we discuss it in their ml. ~harring pgpMTJJ8VjPap.pgp Description: PGP signature
[gentoo-dev] removal of vars from ebuild env
Fair warning, To anyone relying on the vars BUILD_PREFIX, BUILDDIR to be available in the ebuild env, they're going to be yanked down the line; right now, going by scans nobody relies on them- so... please keep it that way. Thanks, ~harring pgpjVDBwDVZS4.pgp Description: PGP signature
Re: [gentoo-portage-dev] Environment Whitelisting
On Mon, Aug 22, 2005 at 11:33:23PM +0200, Marius Mauch wrote: Theoretical discussions about this are pointless IMO without numbers/facts to back things up. I'd posit theroetical discussions about this are pointless without getting ebuild dev's to give a yay/nay on whether they want it or not; not much for trying to force it down their throats if they don't want it (more work, essentially). ~harring pgpGgF8NBM8lW.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
On Sat, Aug 20, 2005 at 01:13:37PM -0400, Nathan L. Adams wrote: Chris Gianelloni wrote: Reviewing an ebuild has nothing to do with inclusion. For inclusion in the tree, it also needs to be tested. You don't take the slightest look at an ebuild (the code) before including it? Anyhow, whether its testing or code review, it is time better spent than cooking up conspiracy theories about me vs. the games team and posting it to the mailing list. Bleh, word play/this isn't needed, as spanky said it's a waste. Inclussion == commit to the tree, available via rsync. Review, and testing are both required. ~harring pgp8UTwCj68nk.pgp Description: PGP signature
Re: [gentoo-dev] Local USE defaults
On Fri, Aug 19, 2005 at 12:10:44AM -0700, Donnie Berkholz wrote: Brian Harring wrote: | Yeah, but the angle I'm pushing for default IUSE's ...er.. use is | eliminating no* flags, and giving ebuild maintainers more flexibility | in breaking the package down into conditionals. | | I really don't see -* being all that useful long term frankly, since | the major usage of it I've seen is either within cascaded profiles, or | nuking autouse; people do block profile use flags also, but killing | autouse falls in with killing profiles :) I don't think that having -* not actually do -* is a good idea. And most people adding local flags don't really consider the -* case so creating no* flags isn't a major concern. ~From my POV, -* is expected to not work well, but it should do what it suggests: subtract everything. Meh. -* 's meaning right now is to nuke all USE flags that portage tries to 'help' in adding. Having it nuke all default use seems wrong, since people *currently* use -* to block autouse crap, and -* isn't what they signed up for initially. Different flag imo seems wise, rather then grandfathering people into it; nuking what the profile offers should be available, but I don't think nuking default IUSE should be nuked as an added bonus of trying to disable auto-use/profile cruft. Thoughts? ~harring pgpbkcy5u7w33.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thu, Aug 18, 2005 at 11:37:05AM -0400, Chris Gianelloni wrote: Other distributions are also binary-only, so there's no real comparison here. While I think having client and server type USE-flags is really a bad idea, I don't see a problem with providing a library. I 100% disagree with splitting the package into client and server, but don't think it would be bad to have it like this: net-libs/libmysqlclient dev-db/mysql You'll notice that there is no server package. The dev-db mysql package should be the entire distribution. Splitting out a separate library for client-only shouldn't be too bad, but I still disagree with it, for the most part. Splitting it out is just as bad as breaking it into server/client chunks from the added QA and maintenance standpoint, thing is, in this case splitting out the lib *is* breaking it up into subpackages, so it's no better :) Best solution in my opinon? Two use flags address this, client, and server. Regardless of the setting of the two, you get the library; from there, you just set client and server as defaulting to on, and packages use dep on whatever chunk of it they need (quite likely no use dep in this case, since they probably only need the lib). Better tweak to it is not the usual use.defaults addition, but specifying the default state of the USE flag in IUSE, as proposed by spanky/others. Kind of curious about people's opinion on the IUSE default use flag thing, initial syntax was (using the above example) IUSE=+client server with client defaulting to on unless the user's config disables it- note, strictly enabling from IUSE, no auto-negation. I forgot to add this, but it's a 10 line change if people still view it as worthwhile. ~harring pgp2ePYxRLr1q.pgp Description: PGP signature
Re: [gentoo-dev] Local USE defaults
On Thu, Aug 18, 2005 at 09:08:51AM -0700, Donnie Berkholz wrote: Brian Harring wrote: | Kind of curious about people's opinion on the IUSE default use flag | thing, initial syntax was (using the above example) | IUSE=+client server | with client defaulting to on unless the user's config disables it- | note, strictly enabling from IUSE, no auto-negation. | I forgot to add this, but it's a 10 line change if people still view | it as worthwhile. Yes, very. Saves us from hacky local USE flag handling by naming them no* or adding them to profiles. Which then raises the question of whether or not -* in a users USE should disable it. I say no, since -* is mainly for killing off auto-use crap and profiles. Note that explicitly disabling a flag (-client fex) would disable the default use there; question is whether or not some form of -* should exist for default IUSE; the existing -* is profile/autouse specific, and sholdn't be reused for disabling default IUSE imo. yay/nay? ~harring pgprwD3lYljfK.pgp Description: PGP signature
Re: [gentoo-dev] Local USE defaults
On Thu, Aug 18, 2005 at 01:16:05PM -0400, Alec Warner wrote: As long as there is a way provided disable the 'default use flags' in this case referring to the IUSE=+foo stuff, with a big warning that says crap generally isn't expected to work great with that setting on, then thats fine. I can see something like a profile setting for this, since embedded may not want the same IUSE defaults as AMD64 multilib...this also saves the profiles from becoming huge with Hi turn this default flag off, and that flag off, and this flag on... crud. See... -* shouldn't affect default IUSE. Why? Because if you make it flip off the ebuilds default use flags, you're forcing the ebuild to start using no* flags instead. Ebuilds are unconfigured- there are default IUSE serves purely as a way for the ebuild maintainer to allow the ebuild to be broken down further- they can do it now, by adding a crapload of no* flags. Allowing -* to castrate default IUSE forces them back into no* flags. Literally, for the embedded example, they already probably have all of the no* flags flipped on if needed- an action was taken, you just change it so it's USE=-theflag rather then USE=noflag. Either way, the work involved is effectively the same. Either way, profiles shouldn't be screwing with the ebuilds in that fashion imo. Note this assuming this feature isn't used as a way to do 'suggested deps', where you start flipping on by default a lot of functionality the user didn't explicitly request (ala autouse). A default of +perl on mysql I'd view as wrong, for example. ~harring pgpN7SaPBH5xd.pgp Description: PGP signature
Re: [gentoo-dev] Local USE defaults
On Thu, Aug 18, 2005 at 01:18:17PM -0400, Mike Frysinger wrote: Yes, very. Saves us from hacky local USE flag handling by naming them no* or adding them to profiles. Which then raises the question of whether or not -* in a users USE should disable it. I say no, since -* is mainly for killing off auto-use crap and profiles. doesnt matter to me one way or the other ... may be confusing to users though who do `USE=-* emerge blah -pv` and see flags enabled Yeah, but the angle I'm pushing for default IUSE's ...er.. use is eliminating no* flags, and giving ebuild maintainers more flexibility in breaking the package down into conditionals. I really don't see -* being all that useful long term frankly, since the major usage of it I've seen is either within cascaded profiles, or nuking autouse; people do block profile use flags also, but killing autouse falls in with killing profiles :) ~harring pgpkDrwhvMgCp.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thu, Aug 18, 2005 at 06:24:03PM +0100, Ciaran McCreesh wrote: On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Best solution in my opinon? Two use flags address this, client, and | server. Regardless of the setting of the two, you get the library; | from there, you just set client and server as defaulting to on, and | packages use dep on whatever chunk of it they need (quite likely no | use dep in this case, since they probably only need the lib). We went over this already. Englighten me, since the issues I'm groking from this I'm fairly sure I already stated/covered :) We can't have client and server USE flags because the meaning is totally different for every package. Plus the 'probably' really isn't good enough, since there are some packages that have more specific dependency and the current die in pkg_setup stuff is a real pain -- do we really want to see that becoming a regular occurrence? You're a bit vague in the 'die in pkg_setup' bit; if you're referencing doing the changes now, and sticking a die in, I already explicitly stated the responsible party would need a wedgie if it was done; the lets check for use flags on our deps in pkg_setup is evil as hell, and *only* should be used when absolutely explicitly required. iow, wait for use deps unless you've got some damn good reason to fall back to the kludge while waiting. Other angle I see is if you're referencing naming the vars in mutually exclusive use flags; if that's the case, I'll just point out that the use flag names in the suggested solution aren't mutually exclusive. Re: probably, it's a comment on the packages that depend on mysql; will they 'probably' require the library (meaning no use dep with the flag configuration above), or will they require the client and/or server chunks (requiring use flags on). Not advocating loose depends if that's how you read it, just added bonus for most packages that dep on mysql that it's use configuration wouldn't require use deps. We can't have client and server USE flags because the meaning is totally different for every package. Meh, I disagree without counter examples provided of where client/server breaks down as a global use flag :) Either way, in this case it *does* make sense, and going with any *only style route makes the flags mutually exclusive (bad). So the alternative names would have to be...? One comment on mutually exclusive use flags/confutils bit- I've asked before and never gotten a decent response, but I'd like to see mutually exclusive use flags represented somehow in an ebuild- preferably a seperate metadata key, and probably requiring the addition of an xor operator to dep syntax. Pretty much just represent the conflicts, and what flags are dependant on one another. Bit ambivalent about that latter part however, since I gtk/gtk2 interaction is a sore point in the tree from where I'm sit. ~harring pgpS67k6LlDzV.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Fri, Aug 19, 2005 at 01:06:35AM +0100, Ciaran McCreesh wrote: On Thu, 18 Aug 2005 13:13:56 -0500 Brian Harring [EMAIL PROTECTED] wrote: | You're a bit vague in the 'die in pkg_setup' bit; if you're | referencing doing the changes now, and sticking a die in, I already | explicitly stated the responsible party would need a wedgie if it was | done; the lets check for use flags on our deps in pkg_setup is evil | as hell, and *only* should be used when absolutely explicitly | required. iow, wait for use deps unless you've got some damn good | reason to fall back to the kludge while waiting. For how many years have we been waiting for USE deps? I'd say that this discussion is pretty much pointless. In the distant future when we do get USE deps we'll no doubt have a whole different set of issues to figure out. USE deps have been sitting in core rewrite's cvs since monday. ~harring pgpEp8FM2N59y.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Fri, Aug 19, 2005 at 05:30:42AM +0200, Christian Parpart wrote: On Thursday 18 August 2005 17:44, Chris Gianelloni wrote: On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: 2) ebuild maintenance will be a nightmare- every new version will require again walking the source to see if the lines you've drawn for dividing the source are still proper. minimize the duplication by a mysql eclass, just like we do for apache e.g. (and lots of others) that prevent us from code duplication. Point was you would have to inspect each release to ensure it still fits. If upstream does this for you, it's not any more of an issue then normal QA. Yes this is being anal (re: the verification), but it's proper QA ultimately. I'd see no problem with this in mysql, if, for example, mysql's Makefile had a make libmysqlclient target. In that case, I would make it a separate package. Having a look at the already provided libmysqlclient ebuild [1] it obviousely (and for our luck) looks like upstream supports this installation types. Multiple configure/builds required- also is worth verifying that building the client/server against the lib does just that, uses existing on disk lib rather then rebuilding. Why? What package would depend on the server in particular? If the user wants the server to be run on localhost, than he would just have to add it to his emerge args as well. I see no problems there - instead: it would be a great enheancement. (IMO) All in all, I think it isn't worth even attempting at this time. read above. do you still think so? If so, why? Increased configuration run time per upgrades, two packages two maintain; why is that an issue? 1) dev-db/mysql must dep on the matching lib version. $PV address this, mostly. 2) 2 packages to handle in p.mask and for doing keywording changes 3) 2 packages to handle at the user side of things for keywording/masking. Real strong points I'm sure; key thing about all of this is that it's increased A) work, B) manual steps required (read: points of screwup). All of the args come down to that, extra complexity/work. If I saw mysql as being loosely bound between it's server and lib components, I'd think it was good to potential chunk into two packages. I don't, obviously. Use conditionals exist *exactly* for user choice like this (iow you've got the tools already to keep it contained as one). That's honestly the strongest arg I can make; the limiting factor is that you're stuck waiting since use dep's aren't available yet. ~harring pgpLZt9RKYQVt.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH] sane USE_EXPAND + IUSE check
Hola-
basically, use_expand'd vars need to be exempted from IUSE checks, as
long as the USE_EXPAND var is in IUSE.
This does that.
~harring
Index: ebuild.sh
===
RCS file: /var/cvsroot/gentoo-src/portage/bin/ebuild.sh,v
retrieving revision 1.201.2.40
diff -u -r1.201.2.40 ebuild.sh
--- ebuild.sh 9 Aug 2005 11:25:44 - 1.201.2.40
+++ ebuild.sh 17 Aug 2005 00:50:27 -
@@ -15,6 +15,7 @@
if [ -f ${T}/environment ]; then
source ${T}/environment /dev/null
fi
+ USE_EXPAND=$(echo ${USE_EXPAND} | tr A-Z a-z)
fi
if [ -n $# ]; then
@@ -130,7 +131,19 @@
# Make sure we have this USE flag in IUSE
if ! hasq ${u} ${IUSE} ${E_IUSE} ! hasq ${u} ${PORTAGE_ARCHLIST}
selinux; then
- echo QA Notice: USE Flag '${u}' not in IUSE for
${CATEGORY}/${PF} 2
+ local x
+ local invalid=1
+ for x in ${USE_EXPAND}; do
+ if [ ${u:0:${#x}} == ${x} ]; then
+ if hasq ${x} ${IUSE} ${E_IUSE}; then
+ unset invalid
+ fi
+ break
+ fi
+ done
+ if [ -n ${invalid} ]; then
+ echo QA Notice: USE Flag '${u}' not in IUSE for
${CATEGORY}/${PF} 2
+ fi
fi
for x in ${USE}; do
pgpVlG8eJOxdX.pgp
Description: PGP signature
Re: [gentoo-portage-dev] Next major version
On Fri, Aug 12, 2005 at 12:04:34PM -0400, Kristian Benoit wrote: I remember, when I started using Gentoo, reading that portage is a stand alone tool, it is not bind into Gentoo in anyway, someone could use it on redhat, debian, lfs... Nice intention, but impossible with stable/alpha code- the abstractions are missing. No config abstractions, but more importantly no format abstractions; no true package object. Back then I was using lfs so I thought portage could be the way to go on lfs, but I realized that Gentoo fit my needs and I did'nt have to compile everything by hand anymore and still have everything compiled by my machines :) OH JOY !!! Heh, came via the route I did... But 5 years or so later, the only official place to get portage releases is still in the gentoo mirrors. There is no RSS feed or anything like that. I still believe that portage has the potential to be so powerful that redhat, debian, ... could be building their packages using portage, managing their own tree, having night build. The problem is see, is that the initial portage vision (or perhaps my initial vision, a vision I still have) has not been carried along with it's developpement. The vision got blocked by the implementation. Try busting all of the globals out of portage, then abstracting all ebuild specific actions (doebuild) behind package apis, so that different formats can be swapped on the fly. Hell, binding dbapi and *tree classes together into one, and having them properly inherited from a base is required, rather then lots of duplicated code. From there, how do you represent the *depends of a package, so that the resolver can be reused across different configurations of package format (this box being rpm, that being ebuild fex); need to break it down into restrictions, handing the actual depends matching off to repositories, with the resolver shifting sets of returned packages/restrictions around to build up a graph. Either way, look at gentoo-src/portage/portage and gentoo-src/portage/rewrite-misc Work is underway, help is needed, jump in and start digging :) The design *should* allow for lots of crazy crap, although anyone who sees a flaw please speak up now :) Having an official web site, doc, ... will help getting visibility and effort from the rest of the world thus we'll have better tools and eventually extend portage beyond Gentoo. API for tools, a *sane* api moreso :) ~harring pgptbc6oHdG5T.pgp Description: PGP signature
Re: [gentoo-dev] Modular X plans
On Tue, Aug 09, 2005 at 07:36:31AM -0500, Caleb Tennis wrote: On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote: If you could bring up some specific examples, we could discuss them. Sure. Qt has optional support for xkb, tablet, fontconfig, xrender, xrandr, xcursor, xinerama (already a use flag), xshape, and xsm. I'd really hate to add 8 more use flags for those things. I find it fairly hard to believe that a user would want to, for example, configre xrender and xcursor but not xrandr. My *thought* here is why not let the Qt ebuild rely on the base packages of X, and if these other packages are also installed ahead of time, then configure support for them as well, but don't make them use flag deps. Something like: if xcursor is installed turn on xcursor support DEPEND+=xcursor fi I'm sure someone will cast me as a heretic, but I think this is much more elegant than 8 more use flags. Yep, you're a heretic. :) How would you propose that DEPEND information make it's way up the portage stack, and ultimately affects the depgraph? What you're suggesting is effectively suggested deps, which are a bit backwards considering we have optional deps, the 8 flags you dislike :) ~harring pgpQeXiqrH1BU.pgp Description: PGP signature
Re: [gentoo-dev] Re: where goes Gentoo?
On Fri, Aug 05, 2005 at 10:59:23AM +0200, Sune Kloppenborg Jeppesen wrote: On Friday 05 August 2005 03:40, Brian D. Harring wrote: On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote: It's not an overnight thing, glep19 (stable portage tree) addresses a chunk of concerns when/if it's implemented, but I'm a bit more interested in the the other tools people desire alongside. Offhand, responding to my own snippet, I'd love to know what's going on with glep19... Not much lately I'm afraid:-/ If anyone is willing to help out I guess a mail to [EMAIL PROTECTED] might get it all (re)started. Might be better stating what's needed... A) people know what they're inadvertantly getting themselves into B) something might be bloody simple to somebody, and they pick it off when they may not have been willing to take the time and poke and find out what's up C) alternatives might be proposed... So... spill the beans. :P ~harring pgpCjv1R0qwnv.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Enterprise deployment tools
On Tue, Jun 21, 2005 at 08:35:52PM +0200, Thierry Carrez wrote: I don't say that it cannot be done, and I don't ask what's the best way to do it. I just ask *if* we should try to provide higher-level tools (and/or doc) to help in doing so. It's not obvious (especially for non-developers) how to proceed in that situation, even if a lot of people have designed their own solution in their corner. Best way to do it? Scary notion, not the way we're doing it currently. Push mode is preferable imo, 'cept no code exists to support that. Someone could write the necessary client/server code, but that would have issues when bound into existing portage apis... With automatic deployments, would we run into difficult-to-solve etc-update problems ? Should/could the ServicePack system take care of that ? I wouldn't use etc-update for this on a enterprise rollout personally. If you need config cfengine does a nice job, as well as using cvs/rcs/something-else Again, the technology is out there, it's just not tightly integrated. Should we leave it as-is and let everyone design his own tools to connect the dots or should we ? Not sure if the technology persay is out there honestly. If it were a cluster, cloned boxes, I'd say minimalize CONFIG_PROTECT, and (assuming you write the client/server cruft above) slip in config pkgs that get installed alongside... or, just jam the config changes into the pkg (not clean but it's possible). Or just trigger staggered reboot's on the boxes if you've got a fast network and pxe boot + imaging setup (I like the other method a bit more however :) If you're managing a half dozen servers, each server running it's own customized httpd.conf, I don't see an easy way to handle that (would love to hear any ideas people have on that one). Basically, kind of curious of how one could easily handle config management of multiple boxes, with config's potentially being wildly different from system to system (talking about a bit more then just /etc/conf.d/net.* and /etc/hostname differences here). I suspect just wrapping the config changes into a bingpkg, and sliding them out alongside on a push would suffice, but that's just one possible method. Even in a simpler setup (preprod production) we don't have the tools to push a software configuration change from a test machine to a production one. What exactly are you looking for here? Should we provide high-level software that defines an update pack (new binaries + configuration changes), allows to test it on a preproduction system and (once tested) to push it to registered production systems ? Or let everyone write his own treefreezing + network mounts + shell scripts + cfengine / CVS magic combo to do it ? How do you push it? I don't mean, what protocol/underlying, I'm asking how do you actually push _portage_ to do what you want? Either you try and abuse the craptastic api in stable to pull it off, or you probably resort to a catalyst akin trick of calling emerge via system. Neither is a proper solution. Api is required, further, preferably portage innards being designed such that you can swap in your own remote subsystem (whether cache tree or config) so it's a matter of pushing commands down the client/server pipes, with the portage config/installation on that box pulling what it needs (remote tree == having to pull all relevant files if building, binpkg is easier however). Portage needs work; I know the devs are working on it, I know there are other people who are doing there own things. I see a lot of portage-2.1 features that greatly simplify what you are trying to do ( repositories, config rewrite..etc.. ). I think portage and what it covers is a big part of this. Recollecting a conversation with jstubbs about portage he mentioned that he wouldn't want the portage-team to maintain a Enterprise-like distribution program, but that the new API would be great to write one against ;) I don't think it should be the role of the portage-team either. I draw a slightly finer line... portaged, some hypothetical client/server ap, not our business to implement, just provide an api for them to use. Thing is, if they're going remote, they'll either need to be able to trigger sync's on the boxes local tree (innefficient as all hell), or the tree is remote. If the tree is remote, that falls on portage devs head to provide a framework so the tree can be remote, in other words abstraction/framework design. Further... if you're pushing updates out, you need some method to query the vdb from the target- even if you're dealing with pushing updates down to a set of identical installations, you need to identify (easily/cleanly) what needs to be built, and what needs to be pushed down the line. Dancing around it, but you need access to the vdb for that system definition, which probably would be stored locally... in which case, the system targets
Re: [gentoo-dev] Bugzilla Bug 79337 make repoman complain if DEPEND and RDEPEND are not set.
On Wed, Jun 01, 2005 at 11:25:00PM +0900, Jason Stubbs wrote:
I'd be for having RDEPEND required to be set manually. ;)
As would I, actually...
Granted it's a useful convenience, but it also makes nailing the deps
down much harder. Personally down the line, I'd like to see packages
that require compilation actually stating the virtual/gcc dep, and
RDEPEND=${RDEPEND-${DEPEND}} kind of screws with that.
But seeing that it would be a huge task and there aren't the resources or
support to do it at this time,
Question is which is preferable.
Changing half the tree is a pita granted and not something to be done
drop of the hat, but that doesn't mean can't decide to change how
things are done, and work towards it gradually.
Writing out a helper script wouldn't be too hard, nor would a script
that does the actual changes- just lift it from ebuild.sh (RDEPEND and
E_RDEPEND are kept seperate till post sourcing).
Anyway, not much point in increasing an already overflowing workload at this
point in time.
I'm mainly interested if people agree with the convenience feature
being worthwhile to keep; I don't think so, but I also occasionally
have strange ideas :)
Again, note, if people did agree rdepend=${rdepend-${depend}} was
evil, it's not a massive treewide commit to change it; just would
require gradually adding explicit rdepend into ebuilds till it's
done, then ixnaying the convenience feature. Same type of changes
gradually rolled out for use and has's verbosity (making them no
longer echo the result)...
~harring
pgpWj1rbeYFxG.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] Treewide metadata.xml
On Fri, May 27, 2005 at 01:47:37PM +0200, Danny van Dyk wrote: Hi Brian What's the gain, aside from implication of collapsing it into a single file? Honestly my only use for metadata.xml is looking up who I get to poke about fixing broken ebuilds... The gain is: ... that you portage people could use it for emerge -s instead of using a DESCRIPTION-cache. 'you portage people' ? :) ... we don't need to find the metadata.xml file before parsing it. Portage's emerge -s doesn't use metadata.xml. Guessing you meant emerge -S (--searchDesc), but that too, doesn't use metadata.xml. So, a few implications in what you mean/are after then. 1) This global description cache would have to be duplicated, and recreated on cvs-rsync runs. Why? Unless you're padding extra bytes in the description cache, updates _will_ kill performance. Personally, I'm not much for it because there is a minimal window for cvs-rsync infra-side to get it's thing done, and this will jack up the runtime. 2) You're still doing entry by entry. Y'all are assuming having this data shoved into one file is going to make it quicker for reads (in reality, you're still reading 19000+ records, just your solution is out of a single file). This may be quicker due to syscall overhead, but I posit the drawbacks aren't worth it. 3) This complicates the hell out of cache updates, and still suffers the same issues eix/esearch suffer- namely that it's not sensitive to cache updates. If we make it sensitive to cache updates, you're looking at regen runtimes going through the roof (see #1 comment on updates). This is regardless of if it's a duplication approach or description is stored in it's own db outside of the normal flat_list cache files. 4) This proposal breaks the cache up into seperate chunks. That's the cache backends decision frankly, and _cannot_ be imposed onto the cache backend implementation from above. I moved eclass data into the cache backend in cvs head explicitly for the purpose of allowing the cache to be effectively standalone, and able to be bound to a remote tree. You force this change from above, it breaks the cache design (pure and simple), and ultimately isn't what you're after (see below). Frankly, any comments that this is going to make things faster are ignoring the existing code. Why is emerge -S so damned slow? Better question, why is it that a mysql cache backend _still_ is so damned slow on emerge -S? That should be hella fast compared to opening 19000 files, right? Because the current stable cache design allows *only* for individual record lookups. In other words, even with an rdbms implementation, it goes record by record. What is needed is a way to hand off to the cache hey you, give me all cpv's that have metadata that matches this criteria. Move the lookup/searching into the cache backend, which is already built into the cache refactoring I wrote for cvs head. If you want to collapse all of the description data into some faster lookup, fine, do so _strictly_ within that cache backend, and modify that class so that it has an appropriate get_matches lookup that's able to do a specific metadata lookup faster. People are free to disgaree mind you, but this talk of speed gains frankly seems to be missing the boat on how our cache actually works, let alone the issues with it. Collapsing all metadata down into a single file, yeah that would be nifty from the standpoint of less files/wasted space on fs's. Centralized DESCRIPTION cache implemented in xml? Eh... ~brian pgpROvbIkKbMs.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Tue, May 24, 2005 at 11:07:54AM +0100, Ciaran McCreesh wrote:
On Tue, 24 May 2005 11:53:30 +0200 Michael Haubenwallner
[EMAIL PROTECTED] wrote:
| Variables to be set by portage:
| PREFIX=/home/haubi
| AFFIX=home/haubi/ (not used here)
Hrm. So what do we use for finding out where our non-home deps are
installed then?
add a bash func that abuses the ebd pipes to query
portage directly.
get_installed_prefix ${atom} might fly, although naming/ironing out
semantics is required.
~brian
pgp3BQNKv9m2m.pgp
Description: PGP signature
Re: [gentoo-dev] Another call for BugVoting on bugs.gentoo.org
On Tue, May 17, 2005 at 09:58:43AM +0200, Thierry Carrez wrote: Stefan Schweizer wrote: Many bugs in bugzilla have ebuilds contributed, the work is done, there is just no developer to add them to the tree and review them. Bugvoting would allow other developers to see where they can help. For example I am using kde but dont read all kde bugs, so if I would know there is a kde bug with many votes I would maybe look at it. I have mixed feelings about this. Voting would be useful to judge which package gathers sufficient popularity to be added to Portage for example. Currently only packages a developer cares for are added, voting would help to get user opinion. On the other hand, on base system bugs for example voting would be more a pressure tool that might not help much... We could enable voting on a New Ebuilds section and see how it goes ? Seems like a good approach in my opinion. Most of the nays have basically come down to I don't want people voting on stuff I'm working on, I know what needs to be done, don't need extra input to discern it. Ebuild submissions fall squarely outside of that arguement, and would be a good test run of it. Personally, I'd be interested in it for actual portage bugs; that said, I'm not totally sure if I'd want it enabled _now_ since there are internal changes needed rather then more feature bloat, so voting would be ignored till internal bits are done. My 2 cents... ~harring -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: New category proposal
On Tue, May 10, 2005 at 10:59:42PM -0700, Duncan wrote: Since our tree layout is based upon category, if you tried shifting the focus of it to packages_in anyway_, you would explicitly disallow same name packages, different category. Doesn't matter how you structure the tree, if you do lookup into the tree based on package, not category, you disallow same named packages. While I'm not a flat tree supporter per se, duplicate packages are IMO a bad thing in any case, for two reasons. 1) Human. It's frustrating to do emerge sudo and have it tell you to specify, when there's only /one/ normal sudo. The /other/ sudo should be vim-sudo or whatever, as you mention later. Yeah, it's usually something I hit everytime I build a new box- it is valid though, and I think it makes sense. app-vim/sudo makes sense in the context of the category, just the same as app-admin/sudo does. While frustrating, I still posit it's not a huge problem. The actual number of conflicts I haven't looked up, but I would expect it's not huge in comparison to the # of packages we have. 2) Bin-pkgs. As currently structured, we have a de-facto flat bin-pkgs layout anyway, since the tree is simply a bunch of symlinks pointing to the $PKGDIR/All dir that /all/ the packages land in. Clashing packages is NOT a good thing, as I'm sure you are aware. /Something/ really needs to be done about this one. Any possible light at the end of the tunnel here? Binpkgs implementation sucks. The current slap em all in a dir and abuse symlinks bit can be dodged down the line. BTW, it'd be very handy to have slotted bin-pkgs as well, slotted as in allowing me to do things like test a gcc4 created package, without erasing my gcc-3.4 created bin-pkg, in case something doesn't work, and without having to remember to manually copy/move the existing bin-pkg first to keep that backup. A feature to enable some arbitrary identifier in the binpkg name, or an arbitrary string as a binpkg subdir path fragment, would be very helpful. Something like FEATURES=binpkg-name then enabling a BINPKG-NAME=gcc4, to then either create a $PKGDIR/gcc4 subtree, or $PKGDIR/All/package-version.gcc4.tbz2 type package and appropriate symlink. One could then just remember to change the $BINPKG-NAME entry in make.conf whenever one runs gcc-config, or whenever one triggers whatever switch and desires a corresponding binpkg-slot change. Anything like this in the works? Umm. yes? Cleanup of stuff in general is in the works, including (done when it's done) binpkg handling being tweaked, which may or may not cover the huge-ass block of requests above :) Should I file an enhancement bug? Maybe the ability is there already and I just don't know it, as with the very cool make.conf source feature I saw mentioned on the amd64 list? BTW2, does the . shortcut work in make.conf? I can envision a make.conf that's simply a half dozen or so lines of source /etc/portage/make.network.conf, . /etc/portage/make.useflags.conf, etc. Is that documented anywhere, yet? When (version) was it introduced? Source works, not sure when it was added, but it's not source in the sense of bash's source; it just makes the make.conf interpretter/parser (it's not bash based) go and read whatever it's pointed at. 2.0.51.19 has it at least, possibly earlier. '.' however doesn't fly, from what I can see source wise at least. ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] dev-lang/icc and dev-lang/ifc candidates for removal
On Wed, May 11, 2005 at 10:11:32AM +0200, Danny van Dyk wrote: Fine, fine this means i can remove them as soon as i pout the new versions in :-) I'm now going to package mask all of icc/ifc. Hmm. mm'kay, get cracking, they'll still get flagged in my script :) These fetching failures are the only reason I even noticed xtv was gone, and the ebuilds have begun collecting a fair amount of open bugs I've only noticed around 10, are the probably even more ? Nope, that's probably about it. Just 10 bugs, with no updates for about a year... :) ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New category proposal
On Wed, May 11, 2005 at 06:01:17PM +0900, Georgi Georgiev wrote: maillog: 11/05/2005-03:40:04(-0500): Brian Harring types On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote: Here's my suggestion, for what it's worth :) The layout on disk and the semantics of categories do not need to be related. Yes and no. You're assuming that people don't use the layout on disk for digging around without calling portage. Personally, I do. I like the idea of using the first character of a package name as the sub-directory name. This can be extended more deeply as and when necessary to avoid over-large directories which cause problems on some filesystems. e.g. for sudo you get s/sudo and vim-sudo v/vim-sudo. This is architecture-neutral, rsyncable, scalable, and not too difficult for users to parse manually (see later for searching through categories). If the algorithm portage would use to locate a package is such that it doesn't mandate the depth (i.e. tries package, p/package if p/ exists, p/a/package if p/a/ exists) then overlays can have a different depth to the rsync tree; if you only have a few packages in overlay then they need not be in subdirectories at all. Re-asserting that the fs layout *does* matter, how is that more intuitive when trying to track down the ebuild for dev-util/diffball ? The fact that the directory where diffball is is easily deducable by its name. As it is, I'd be a bit lost if I had to guess whether diffball is in app-arch or dev-util. Even if I remembered it was something dev-related I'd still be inclined to look in sys-devel. dev-util is accurate (it's a compressor, but a specialized variant, same as patch is). From it's current fs location/layout, we get thus- quick lookup on the atom, and inference of it's intentions. This is why we have xml at the category level, for example. One thing that's being unstated also- it's implicitly stated that this directory structure is somehow easier to look up a package. If you know the _exact_ package name, maybe. Otherwise, you're falling back to a search tool (which defeats to some degree the whole arguement for flattened namespace). Some quicky python, grouping by first char of the package name, and you wind up with (top 8)- 421, 521, 571, 582, 657, 663, 664, 746 Seperate directories within an individual directory. Say 'd' for example, and we'll pretend 746 is the count of packages that start with 'd'. That's a butload of directories to go digging in. The response would be, well then extend it to the first two chars after the first dir. You narrow it down, but add another layer of dirs, again, for what gain? See, the thing I find odd about this thread/request is that essentially breaking it down to first letter groupping, is being argued as being _easier_ for people, while allowing multi cats, or just flat out dropping the category aspect. The example above, imo, proves otherwise. Keep in mind at this point, the discussion is whats easiest for _humans_. What's easiest for code/comp is another matter, and (within limits) can work with anything that's thrown at it. How many directories deep would I have to go before I reached the ebuild? Does it matter? You know the path exactly. It's p/portage. It's not ... was it sys-apps/portage or app-portage/portage? I know the path as sys-apps/portage already though. Doesn't that count for something? :) Or, a bit more likely case, I know the type of the package, the category, but don't recall it's exact name. What y'all are proposing forces the user to use a tool, rather then just a quicky ls. Having said that, some things could be done now. If a flat package namespace is desirable, the existing package name clashes could be resolved by renaming the few packages that clash. 74 packages, roughly, out of 9429 roughly. 76/9295, which is not that bad, considering about half of them are emacs/xemacs related. 'cept either you, or someone else was proposing a totally flat namespace, no cats in the atoms. That means the count of changes (the 76 above is just # of conflicting packages) is around 19000, plus a fairly large amount of portage modifications. Category could be added as a field in metadata.xml, so that a package could belong to multiple categories. The query/search tools could be enhanced to scan this metadata (perhaps including the current category directory as an implied entry in the metadata.xml). If that's the goal of the belong to N categories thread, strictly searching, sure, although I don't like it. It can't become an atom for *DEPEND due to the cpv nonconflicting bit. I personally want to see the category part *disappear* from the *DEPEND which is one of the reasons to advocate a flat tree. If the category (or part of it) goes in the package name, so
Re: [gentoo-dev] Re: New category proposal
On Wed, May 11, 2005 at 11:11:02AM -0400, Alec Warner wrote: Yes and no. You're assuming that people don't use the layout on disk for digging around without calling portage. Personally, I do. Not need to be related, but shouldn't be related. In essence this allows people to put the tree where-ever, as long as that storage mechanism supports the database operations required ( stuffing everything in a SQL db fex ). I don't know why someone wouldbut hey ;) Not a valid arguement for dropping categories however, since I'm playing with sqlite based repository module atm locally :) (don't ask for it, it's not even remotely ready for any use beyond destroying things locally on my box at the moment) Category is just a bit of info used for looking up a node (category=xyz and package=abc). Shouldn't isn't applicable here; in this case, category *is* required due to our atoms, unless people manage to push flattening the namespace through. :) The fact that the directory where diffball is is easily deducable by its name. As it is, I'd be a bit lost if I had to guess whether diffball is in app-arch or dev-util. Even if I remembered it was something dev-related I'd still be inclined to look in sys-devel. dev-util is accurate (it's a compressor, but a specialized variant, same as patch is). From it's current fs location/layout, we get thus- quick lookup on the atom, and inference of it's intentions. This is why we have xml at the category level, for example. One thing that's being unstated also- it's implicitly stated that this directory structure is somehow easier to look up a package. If you know the _exact_ package name, maybe. Otherwise, you're falling back to a search tool (which defeats to some degree the whole arguement for flattened namespace). Some quicky python, grouping by first char of the package name, and you wind up with (top 8)- 421, 521, 571, 582, 657, 663, 664, 746 Assuming the directories are ordered by letter, ( a,b,c,d ) and subdirectories if present as well, a bsearch wouldn't be bad. Both are ordered sets and you can quickly determine the location of a package in log(n) time. I don't see a big deal here. Dodging my point though. I was pointing out that the categories approach decreases the number of directories/packages within each grouping, while first letter approach jacks up the # of dirs w/in dirs (in some cases, of course). basically, a category fs layout is easier on the human who is digging in if they don't know what they're exactly hunting for, point still stands. :) Regarding bsearch, ehh. listdir returns a list (not an iterable over the (open|read|close)dir syscall), so you'd have to either resort to a linear search, or sort then bsearch it. Like I said, the issue isn't how we code things to make it speedy, my concern outlined above is purely the human factor in dealing with the proposed tree structure. I know the path as sys-apps/portage already though. Doesn't that count for something? :) Or, a bit more likely case, I know the type of the package, the category, but don't recall it's exact name. What y'all are proposing forces the user to use a tool, rather then just a quicky ls. *tongue in cheek* and what is ls but another tool for listing the contents of a directory :) ls does no good if you're trying to see all packages of a category, under this proposal, which is what I'm driving at. It forces the user to use scripts/tools to do querying. I personally want to see the category part *disappear* from the *DEPEND which is one of the reasons to advocate a flat tree. If the category (or part of it) goes in the package name, so be it, but at least there will be no package moves to break older ebuilds or outdated overlays. Frankly, you need to give a *really* damn good reason for why this is better. I don't think it is, convince me otherwise. What do we gain from a flat namespace? Right now, I can infer an atom out of a DEPEND string's purpose to some degree, based upon it's category. To head off the well you don't need to know the category, you should know the packages intentions if you're modifying the ebuild, that dodges the point; via the category portion of an atom, I can infer at least -intention- of a package. The CPV thing.is a big fix :( Ignoring changes required (have stated them already, no point in sniping ya over it), what _exactly_ do we gain from the change? So... what do we gain? Like I said, ignore for a second that massive overhaul required; if work is required to gain something, and what's gained is worth it over the work, sure. I'm not seeing the gain though :) The original request was having a package turn up in multiple categories for searching, right? I don't like it, but metadata.xml at the package level could probably be extended for that, *strictly* for searching. It cannot,
Re: [gentoo-dev] Tests for eclasses
On Tue, May 10, 2005 at 09:54:33PM +0100, Ciaran McCreesh wrote: Is there a standard way of handling testing for utility-type eclasses? For versionator I currently have a __versionator__test_blah function included in the eclass (source versionator.eclass works, it doesn't have any portage-specific code), but this is going to get a bit messy when I add in another few dozen tests... Maybe a simple test harness could be added as an option for the new eclass / elib setup? Elaborate on the tests... ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New category proposal
On Tue, May 10, 2005 at 08:04:04PM +0900, Georgi Georgiev wrote: maillog: 10/05/2005-11:28:21(+0200): Martin Schlemmer types On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote: Georgi Georgiev wrote:[Sun May 08 2005, 08:19:20PM EDT] Would it be inappropriate to start bitching (again) about a flat tree where each package can go in multiple categories? That's something I'd love to see eventually... I mean the flat tree, not the complaining ;-) Problem with flat tree, is the search times might then suck even more, as last I heard, too many dirs/files in one directory have a huge speed penalty. The flat tree does not imply a flat hierarchy on disk. Files and directories can still be organized in a more optimized manner. For example -- put each package in a directory of its first letter. Maybe even two letters if you think that the winner 'g' with 736 packages is too many. This would basically require a totally seperate rsync module for newer portage versions that would handle it. Or portage would have to support both, which (frankly) is something of a no go; it's too fricking ugly imo. Beyond that, drop the optimized manner in reference to speed; addressed below. Optimized for human readability? not so sure, digging through debian's directory structure to dig out certain files has always drove me slightly insane while doing so... This is only true when the portage tree is stored on a filesystem. I recall some effort being made in making portage support reading the portage tree from a zipfile, so we may eventually see some other backends that would not suffer from this problem. Down the line, viable (should be able to basically go nuts in terms of how you store the tree, locally, remotely, etc). Now? eh, tiz a ways off. Regarding speed comments about look up in the tree, frankly it's a bit minor imo. Initial installed package scan is a heavier hit (it's required for even an emerge --help). The bits in this thread about using xyz fs for the tree are trying to address the effects, not the cause of potentially slow cp_list/cp_all lookups; if the tree were marked as frozen (non-modifiable, iow users don't modify an ebuild here and there), and portage had frozen support (working on it), you could work directly from the cache instead, which would be a bit faster (at the very least, less syscalls, (open|close|read)dir, stat'ing, etc). The speed portion of the arg in other words, I don't think is valid. Better to focus on what benefits the poor human who has to go digging through the tree manually, then try to make portage go faster via it w/ dir structuring/underlying fs. Re: having a package claimed by multiple categories... eh. yeah, that's a bit valid although I'd think it's either A) an indiciation our categories need to be adjusted a bit, or B) (hopefully) a rare case. :) My 2 cents, at least. ~Brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New category proposal
On Wed, May 11, 2005 at 01:27:46PM +0900, Georgi Georgiev wrote: As to whether the categories are good or not... think about it. If they were good, would we still be seeing packages moving around the tree? That's why I think that multiple categories are a necessity. Unless of course, packages stop getting moved around and Gentoo can gurantee that all packages will stay at their current location. Keep in mind the tree is in constant flux, new packages added, packages removed, etc. Of course there will be a bit of reorganization, unless we add every possible category under the sun (even then, $10 on some weird esoteric category being requested shortly after such a change) ;) Point I'm getting at is that the need for a better groupping occurs depending on the packages being added. One thing that just clicked in the skull on why flat-tree has issues; currently it's possible to have a package with the same name, yet a differing category (app-vim/sudo vs app-admin/sudo). Since our tree layout is based upon category, if you tried shifting the focus of it to packages_in anyway_, you would explicitly disallow same name packages, different category. Doesn't matter how you structure the tree, if you do lookup into the tree based on package, not category, you disallow same named packages. What about the Mozilla suite. What in the world is it doing in www-client? After all, the Mozilla suite is - a www browser (www-client) - a mail client (mail-client) - a calendar - an html composer - an irc client (net-irc) Might as well go to net-misc :-/ This is why I commented that there are exceptions, question is if the exceptions are annoying enough the level of change required, is implemented (I posit no, but that's cause I see issues w/ the resulting namespace, and am lazy). - I hate the moves of packages between categories which causes enough problems as it is. I also find the arguments of where to put what pointless. Who cares if it is mail-client/mutt or net-mail/mutt as long as it stays in one place and is accessible by its name mutt. If you think that mail-client is more descriptive than net-mail, The category labelling of it matters for those who go groking for an app to use, but don't know the possibilities. Example: well, lets see what mail clients exist, and pick one of 'em for use based upon the description, since I've had it with my current mail client... then add keywords (for those who hate the idea of multiple categories) to the metadata of each package and let emerge -s search by keyword. Does mutt not belong to net-mail? It does, but mail-client is better. Still, that is no reason to remove its relation to net-mail. Cache the keyword information to make the search as fast as possible and you're done with the searchability part. You can now safely forget about this thing called categories as they become irrelevant, and hopefully never move another package. - I also hate being unable to find exactly the package that I need right away. I want to check mutt's ebuild... cd /usr/portage/... what next? Is it at the same place that I remember it was the last time I checked? Do I *have* to know what category it belongs to? Of course I can do cd /usr/portage/*/mutt, but shell completion on the mutt part won't work on this one. Mutt's not quite the example for the necessity of completions, but it gets worse with longer names like mozilla-firefox-bin. Re: yeah, it's fricking annoying, agreed. I'd state a faster tool is preferable, rather then a reorganization (imo). See above about why flattening the tree so it's package-centric rather then category-centric has issues. The consequence is that you have to start moving category specific metadata into the package name when valid conflicts occur- the sudo/vim example above, would require vim-sudo or vim-plugins-sudo. Debian does this, they (ab|)use a flattened namespace. I strongly dislike it, even compared to the consequences of our N category approach. Granted they lack (afaik) category data, but the consequences of flattening the namespace still stands imo. :) So... next possibility is doing the additional categories via extra metadata (xyz is *primarily* cat a, but also is cat b and c). Complaints over speed would easily triple if this was added; if you don't find a package within a (on disk dir) categories namespace, you have to walk the metadata for *all* ebuilds to verify that there isn't another package that has allegance to that category. Yes, this can be cached, but it is a pita and is added complexity (in other words, gains needs to offset this extra cost). - Personal overlays. I think this a point that's clear enough. Gentoo devs may have scripts that keep the tree in sync after the loved-by-all move of a package, but that doesn't apply to us, mere mortals. Got me there. Would need an active translation layer, cpv was
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, May 09, 2005 at 03:46:57AM +0300, Marius Mauch wrote: Brian Harring wrote: Clarify please :) Offhand, I don't see why a bin repo for a home target isn't viable, along with a vdb repo in the same location. It's a bit trickier, but I suspect it might be a bit more flexible in the long run. I don't think that's possible without a lot of hacking for many packages as $HOME will be expanded at build time and might be included in the resulting binaries. Or in other words: If it works, we don't need $PREFIX support at all as packages could be relocated at merge time. Was referencing per home binrepo's; basically (if desired by the admin/user), binpkg backups of per user home targets. End result is per user FEATURES=buildpkg support, with the binpkgs safely tucked away within $HOME of the user. If we're already doing the dep calculation of what nodes are needed, and where (home prefix, or global, etc), don't see why that info can't be tucked away and used as a restriction for the binpkg generated for that particular user... ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles
On Mon, May 09, 2005 at 10:12:03PM +0200, Paul de Vrieze wrote: What about adding a panic mode to portage which, when confronted with a missing profile, (and after confirmation) continues to upgrade portage to the latest version it can find with some default settings that should allways work. Can't see any tenuable way to pull it off; without the profile, keywording can be something of a crapshoot (consider p.mask'ed portage versions, which do, and will continue to, occur). Depends on your definition of default though I spose; I'd expect it would require a portage modification though :) ~brian -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] dev-lang/icc and dev-lang/ifc candidates for removal
Unless someone steps up, the intel compiler toolchain packages dev-lang/icc (intel cc) and dev-lang/ifc (intel fortran compiler) are prime candidates for removal from the tree; open bugs, primary maintainer is retired, and no devs have moved in to pick up the packages, let along touched the changeslogs in around a year. So, any takers? ~brian pgp9LVttTjl09.pgp Description: PGP signature
