Re: [gentoo-portage-dev] Package compression header for binhosts
On Mon, 2010-05-31 at 22:16 -0700, Brian Harring wrote: On Mon, May 31, 2010 at 08:32:34PM -0700, Zac Medico wrote: Hi, In order to support alternative compression types for binhost packages, I was thinking about adding support for a header field in the Packages index file. For example, a header line like PACKAGE_EXTENSION: txz could be used to indicate that clients should download files with txz extensions instead of tbz2 extensions. I'm planning to add support for both tgz [1] and txz extensions. [1] http://bugs.gentoo.org/show_bug.cgi?id=142579 1) requires a version header bump Agreed. But there were some other pending changes for VERSION: 1 Any planned changes to the format should be documented on https://bugs.gentoo.org/show_bug.cgi?id=263994 2) a header alone isn't useful unless it's specifiable per cpv entry; thus it must be inheritable Per CPV entries is going to bloat the format and make me carry around a more data on a per pkg basis then I'd want to. How about we run with zac's idea but use tools to convert a full repo over to $EXTENTION This should keep the portage code fast as well as it checks for invalid binpkgs all the time. Having to have portage process a ton of ever growing extentions is just going to be slow. 3) PACKAGE_EXTENSION is overly verbose and unclear it's specifying the compressor too; it's intention is for compression, state it as such (I mention this in light of URI's existance where PACKAGE_EXTENSION would only be a hint of compressor) Re: #1, there is a decent set of optimizations I'm kicking around in pkgcore for the next version- a discussion should probably be started there. Offhand, having a compression specific header (a simple enumeration of known compressors) and a DEFAULT_URI that is python string No go bro. The 'Packages' format should be independent of python. interpolation assembled (for example, DEFAULT_URI=%(host)s/%(category)s/%(pf)s.txz) seems wiser. Via doing what I'm suggesting, it would be possible to do binpkg repository 'views' w/out having to map each binpkg into the url space for it. ~harring -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] add UUID for comparison of installed package to binary package?
On Sun, 2010-02-14 at 12:11 -0800, Zac Medico wrote: On 02/14/2010 04:36 AM, Brian Harring wrote: This gets nasty... you're basically talking about the rpm equivalent of EPOCH. Not a fan of an adhoc UUID (especially since it'll become standard via portage doing it), but a *timestamp* for the build, labeled as such, gets you what you want and is usable for other things- detecting when to rebuild a scm package for example. That route gets my vote, and should also address your intentions. ~harring Ok, then how about a vdb entry named CTIME that contains an integer number of seconds since the unix Epoch? That would be UNIXTIME vs CTIME I'd think.
Re: [gentoo-portage-dev] pretend --columns depends on --quiet?
On Thu, 2009-05-07 at 10:00 +0300, Amit Dor-Shifer wrote:
Hi.
Seems like --columns depends on -q to work:
amit0 ~ # emerge -p --color=n --columns -O -q portage
Rsys-apps/portage 2.1.6.7
amit0 ~ # emerge -p --color=n --columns -O portage
These are the packages that would be merged, in order:
[ebuild R ] sys-apps/portage
[2.1.6.7]
Is this WAD?
10x,
Amit
Yep. This looks like a bug with the [] part of the atom display.
emerge -p --columns portage \
| grep \\[ebuild \
| awk '{print $4-$5}'
Results: sys-apps/portage-[2.1.6.11]
Quick work around that should be safe would be to
tr '[,]' ' , ' |awk '{print $3-$4}'
It is expected however that -q vs no -q will result in the atoms being
at the same index.
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] pretend --columns depends on --quiet?
On Thu, 2009-05-07 at 13:18 -0700, Zac Medico wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ned Ludd wrote:
On Thu, 2009-05-07 at 10:00 +0300, Amit Dor-Shifer wrote:
Hi.
Seems like --columns depends on -q to work:
amit0 ~ # emerge -p --color=n --columns -O -q portage
Rsys-apps/portage 2.1.6.7
amit0 ~ # emerge -p --color=n --columns -O portage
These are the packages that would be merged, in order:
[ebuild R ] sys-apps/portage
[2.1.6.7]
Is this WAD?
10x,
Amit
Yep. This looks like a bug with the [] part of the atom display.
emerge -p --columns portage \
| grep \\[ebuild \
| awk '{print $4-$5}'
Results: sys-apps/portage-[2.1.6.11]
Quick work around that should be safe would be to
tr '[,]' ' , ' |awk '{print $3-$4}'
It is expected however that -q vs no -q will result in the atoms being
at the same index.
Correction:
It is expected however that -q vs no -q will NOT result in the atoms
being at the same index.
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Sat, 2009-04-18 at 12:55 -0400, Mike Frysinger wrote: On Thursday 16 April 2009 19:05:46 Ned Ludd wrote: On Tue, 2009-03-17 at 10:50 -0700, Ned Ludd wrote: On Tue, 2009-03-17 at 13:27 -0400, Mike Frysinger wrote: On Tuesday 17 March 2009 12:59:58 Ned Ludd wrote: There is also a bug with atom parsing iirc on 32bit platforms. gradm was the test case. Think we need to change from int to long. the code is documented as having 64bit limitations for any specific component. the last release doesnt have the updated work i did in qatom to handle the latest atom spec though, and that includes moving from 32bit to 64bit for components ... Sounds good. Maybe another with -rX parsing. if you're thinking of the open bug, that's an eprefix specific extension. they turned the X in -rX into a floating point #. which isnt supported currently. I don't think that was it. But I can't recall well enough off the top of my head the problem that somebody pointed out to me one day on irc while I was probably too busy. The error was pointed out to me again today on irc by jmbsvicetto and hoffie, which reminded me of what I had forgot before in this thread. The problem was/is that qpkg is not handling -rX extensions properly. you'll have to be more specific. like i said, -rX extensions are a prefix extension and not part of the standard tree and/or spec. i'm not going to implement every random thing that someone feels like adding. -mike Heh. I don't think you understand the problem yet. Not a feature request.. It's a real bug/regression. See the bug# that jmbsvicetto filed this morn about it. https://bugs.gentoo.org/266646
Re: [gentoo-portage-dev] prefix portage chaining
On Thu, 2009-03-26 at 08:26 +0100, Markus Duft wrote: On Wed, 2009-03-25 at 11:44 -0700, Ned Ludd wrote: [snip] While much of what you are talking about here mainly applies to prefix, it looks to me from glancing over the code that you might of solved a long standing problem in the embedded world with cross compiling via portage. 222895 If that is the case, then I owe you a beer. one about the size of a keg. lol, thx for the beer ;) hmm... looking over that patch again, the only EPREFIX dependent thing is, that i'm removing EPREFIX from the vartree class again :) so this should pretty much plain apply to main too, and simply work. you may want to rename READONLY_EPREFIX to READONLY_ROOT, but thats it :) the other stuff besides portage modification (baselayout patchery, etc. is prefix specific again, so all you'd need is the portage changes. if you will try it, please let me know if it worked :) with the attached patch sed -i -e 's,READONLY_EPREFIX,READONLY_ROOT,g', and applying to an installed /usr/lib/portage should enable you to do it. (backup /usr/lib/portage - i trust my work, but... we never know for sure :)) then add to make.conf: READONLY_ROOT=/my/other/root:DEPEND i hope this is what you where looking for...! and i hope it doesn't somehow clash with the existing cross compile logic in portage regarding where to merge to... Cheers, Markus patch failed a few hunks for me on ~arch vanilla-portage. I did point out the patch to one of the gentoo embedded/openmoko guys. Think they will be the most eager to test this. In our case if the code did work out whatever you call READONLY_ROOT we would probably need to expand to allow for more that one ROOT if it has to be defined in the parent /etc/make.conf -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] prefix portage chaining
On Wed, 2009-03-25 at 14:14 +0100, Markus Duft wrote: On Wed, 2009-03-25 at 12:00 +0100, Fabian Groffen wrote: On 20-03-2009 11:35:09 +0100, Markus Duft wrote: i'll try and explain what i want in the first place: i'm porting things to native windows. since windows isn't too cooperative, i'm unable to merge most things (and with other things, i simply don't want to), and thus i need to take those things from somewhere else (more or less the complete @system). I _am_ able to build all those things for interix (which is the host system in the windows case). So what i want is a setup of two prefix instances with a certain relation to each other: the native windows prefix should be able to recognize installed packages from the other instance, and resolve dependencies by eventually using the other .../var/db/... Since Windows and Interix seem to be two different things to me, can you explain why in this case Portage can resolve the dependencies from the Interix system to use for the Windows system? What dependencies are we talking about? Build tools? Libraries? Runtime dependencies? i'm using it to resolve DEPEND atoms only. of course my notion of valid DEPENDs and RDEPENDs is influenced by this, and i'm alergic against RDEPEND=$DEPEND and such :) since it doesn't work in this setup. however right now most things i need don't make too much problems. This could be (and is) quite usefull for all other platforms too. For exmaple i could use prefix chaining on a linux box. I could create a prefix containing a base system, and then for testing of i-don't-know-whatever, i could create another small prefix inheriting all installed packages from the other one. this way new prefixes can stay very slim, but still the parent prefix is not altered on merges. That potentially is useful, in the case where you want to upgrade a critical system package and test it out or something. Can't think of an example other than Portage itself for the moment, though. (And that one can be hairy, for instance if the vdb format changes NEEDED - NEEDED.ELF.2) ++ :) one issue not handled by the current patch is, that prefixes can have different CHOST/ARCH/... (which is the case with x86-interix and x86-winnt for example). Then how does it work for you? as i said, i'm using DEPENDs only from the other prefix with the different CHOST/ARCH. this works, since on interix i can execute windows binaries, and vice versa (limited). the patch i proposed here and on gentoo-alt@ (btw. i have a fixed version lying around since a few minutes ...) allows the user to set which atoms should be resolve-able from the chain. for exmaple for windows i'm doing this in /my/winnt/prefix/etc/make.conf: READONLY_EROOT=/my/interix/prefix:DEPEND on linux, if both prefixes are x86-linux for example i could to in /my/prefix/two/etc/make.conf: READONLY_EROOT=/my/prefix/one:DEPEND,RDEPEND (btw. this forces PDEPENDs to merge in /my/prefix/two. i guess most of the time this makes sense, since with a PDEPEND from a lib, i want the PDEPEND package to link against this lib... you know what i mean? of course PDEPEND can still be added to the above list...) (btw2. the name READONLY_EROOT is discussed on gentoo-alt@ already, so i won't comment on it beeing cool/uncool here... ;) ) Cheers, Markus \ While much of what you are talking about here mainly applies to prefix, it looks to me from glancing over the code that you might of solved a long standing problem in the embedded world with cross compiling via portage. 222895 If that is the case, then I owe you a beer. one about the size of a keg. -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Mon, 2009-03-16 at 19:45 -0400, Mike Frysinger wrote:
On Monday 16 March 2009 18:49:04 Ned Ludd wrote:
On Mon, 2009-03-16 at 17:05 -0400, Mike Frysinger wrote:
On Monday 16 March 2009 14:35:15 Ned Ludd wrote:
On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
Hi all.
While working on my overlay, I stumbled on an issue where qfile
refused to acknowledge an installed file as being part of my package.
Looking into q's implementation (portage-utils-0.1.29), I see:
amit0 portage-utils-0.1.29 # grep -A 2 next_entry
./libq/vdb_get_next_dir.c next_entry:
ret = readdir(dir);
if (ret == NULL) {
--
goto next_entry;
if (strchr(ret-d_name, '-') == NULL)
if ((strcmp(ret-d_name, virtual)) != 0)
goto next_entry;
I encountered this since I used a new category, which only contained
a single word. Adding a hyphen and a 2nd token solved my issue, and
now qfile knows the file's association.
Is this assumption, that category should be stringA-stringB
documented somewhere?
We made that assumption for portage-utils as they can be used on a
device which has no $PORTDIR at all. So when there is no categories
file that exists we fell back to the rules that have been working well
for the past %d years.
We changed that behavior however a while ago. I thought this was in the
tree. But I guess not if you are hitting it.
http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq
/vdb _get_next_dir.c?r1=1.2r2=1.3
we should do a new release already
Why yes.. Yes you should :)
if you dont do it before me, i'll probably try and do it this weekend.
I'd prefer it if you could do it this time. (thanks in advance)
btw, i
went through the bug reports and saw qcache crashes ... are those still
relevant ?
-mike
Yeah. tcort was the guy who wrote most of that. He's retired now.
I never really looked into it much but I think there are some NULL
values he did not check for in the metacache.
There is also a bug with atom parsing iirc on 32bit platforms. gradm was
the test case. Think we need to change from int to long.. Maybe another
with -rX parsing.
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Tue, 2009-03-17 at 13:27 -0400, Mike Frysinger wrote: On Tuesday 17 March 2009 12:59:58 Ned Ludd wrote: There is also a bug with atom parsing iirc on 32bit platforms. gradm was the test case. Think we need to change from int to long. the code is documented as having 64bit limitations for any specific component. the last release doesnt have the updated work i did in qatom to handle the latest atom spec though, and that includes moving from 32bit to 64bit for components ... Sounds good. Maybe another with -rX parsing. if you're thinking of the open bug, that's an eprefix specific extension. they turned the X in -rX into a floating point #. which isnt supported currently. -mike I don't think that was it. But I can't recall well enough off the top of my head the problem that somebody pointed out to me one day on irc while I was probably too busy. -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
Hi all.
While working on my overlay, I stumbled on an issue where qfile refused
to acknowledge an installed file as being part of my package.
Looking into q's implementation (portage-utils-0.1.29), I see:
amit0 portage-utils-0.1.29 # grep -A 2 next_entry ./libq/vdb_get_next_dir.c
next_entry:
ret = readdir(dir);
if (ret == NULL) {
--
goto next_entry;
if (strchr(ret-d_name, '-') == NULL)
if ((strcmp(ret-d_name, virtual)) != 0)
goto next_entry;
I encountered this since I used a new category, which only contained a
single word. Adding a hyphen and a 2nd token solved my issue, and now
qfile knows the file's association.
Is this assumption, that category should be stringA-stringB documented
somewhere?
We made that assumption for portage-utils as they can be used on a
device which has no $PORTDIR at all. So when there is no categories file
that exists we fell back to the rules that have been working well for
the past %d years.
We changed that behavior however a while ago. I thought this was in the
tree. But I guess not if you are hitting it.
http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq/vdb_get_next_dir.c?r1=1.2r2=1.3
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Mon, 2009-03-16 at 17:05 -0400, Mike Frysinger wrote:
On Monday 16 March 2009 14:35:15 Ned Ludd wrote:
On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
Hi all.
While working on my overlay, I stumbled on an issue where qfile refused
to acknowledge an installed file as being part of my package.
Looking into q's implementation (portage-utils-0.1.29), I see:
amit0 portage-utils-0.1.29 # grep -A 2 next_entry
./libq/vdb_get_next_dir.c next_entry:
ret = readdir(dir);
if (ret == NULL) {
--
goto next_entry;
if (strchr(ret-d_name, '-') == NULL)
if ((strcmp(ret-d_name, virtual)) != 0)
goto next_entry;
I encountered this since I used a new category, which only contained a
single word. Adding a hyphen and a 2nd token solved my issue, and now
qfile knows the file's association.
Is this assumption, that category should be stringA-stringB documented
somewhere?
We made that assumption for portage-utils as they can be used on a
device which has no $PORTDIR at all. So when there is no categories file
that exists we fell back to the rules that have been working well for
the past %d years.
We changed that behavior however a while ago. I thought this was in the
tree. But I guess not if you are hitting it.
http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq/vdb
_get_next_dir.c?r1=1.2r2=1.3
we should do a new release already
-mike
Why yes.. Yes you should :)
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] About boosting sync
On Tue, 2008-12-02 at 19:46 +0200, Tambet wrote: Has anyone ever noticed that portage tree contains a lot of md5 hashes, which are not at all important for using it? I think that it does not make reliability or functionality smaller any bit if those would all stay in sync servers - anyway, syncing would go much faster and this tree smaller. What about removing all those md5 hashes and downloading them only when they're needed? To build a deptree portage needs to source the ebuild in the depend phase, so portage needs to know that a file is safe to source before it loads it. Being that FEATURES='strict' is enabled per default in all profiles. It's rather vital that things remain the way they are now. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux
Re: [gentoo-portage-dev] Time to say goodbye
On Sun, 2008-11-30 at 16:19 +0100, Marius Mauch wrote: So, time has come for me to realize that my time with Gentoo is over. I haven't actually been doing much Gentoo work over the last months due to personal reasons (nothing Gentoo related), and I don't see that situation changing in the near future. In fact I've already reassigned or dropped most of my responsibilites in Gentoo a while ago, so there are just a few pet projects left to give away: - my gentoo-stats project (in the portage/gentoo-stats svn repository). I know quite a few people are interested in the idea of collecting various statistic data from gentoo user systems, and I'd encourage everyone who wants to implement such a system to at least look at it (I may have even finished it if I wouldn't have wasted my time focusing on the wrong problems). There is quite a bit of documentation also that should help to get you started - a graphical security update tool (see bug #190397) So if anyone wants to adopt those, complete or just parts, just take them. As for Portage, Zac has practically already filled my role. So I guess that wraps it up. It's been a nice ride most of the time, but now it's time for me to leave the Gentoo train. Marius I will always remember you as the guy who provided us with the much needed glsa*.py (thank you again) Take care and I wish you the best in all your future endeavors. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux
Re: [gentoo-portage-dev] About system and world
On Sun, 2007-10-21 at 15:12 +0200, Marius Mauch wrote: On Sun, 21 Oct 2007 05:23:45 -0700 Ned Ludd [EMAIL PROTECTED] wrote: On Sun, 2007-10-21 at 13:01 +0200, Marius Mauch wrote: So, what do people think about removing (some) of the special treatment for the system and world targets? Mainly I'm interested in removing the selective parameter that's currently enabled for them (so for example without that parameter `emerge world` would default to remerging packages, unless --update or --noreplace are specified). That change has already been requested a few times in the past by users, but OTOH it could probably upset people who don't use --update with world/system. What would such a disruptive change really gain us? The goal is to make package sets behave in a consistent way. I personally feel our users need consistency from Gentoo. If they grew up doing 'emerge world' and have come to expect that behavior and all of the sudden we change behavior on them.. Yeah I can see how ppl would get upset. As do I, which is why I haven't simply changed it. Perhaps a less intrusive way would be to introduce another flag to get the specified behavior you are after. Well, the primary goal is to make all sets behave in a consistent way. And some sets have the explicit purpose to rebuild stuff, so making sets selective by default also has issues. The proposed change would also make sets behave in the same way as packages which is IMO another benefit. But as I said, I can see that it could upset people. One possible solution that I've thought about would be to remove the hardcoded selective parameter and let the set configuration determine if a set is selective or not (with missing = false), and then enable it for world and system in our default config, e.g. [world] class = portage.sets.files.WorldSet selective = True and extend the --rebuild option with new arguments always and never. Don't really like the additional complexity though (and I haven't checked how much work it would be). To me this really sounds like it's -e world but just with the world file. Literally as if you were to do an emerge -p $(/var/lib/portage/world) Assuming that is what you intend for it to behave like then how about using -E for this behavior? Everybody would profit and nobody would become disgruntled when all of the sudden emerge started spiking the power bills. :) -- Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] LC_ALL and friends in make.conf
On Thu, 2007-03-08 at 14:23 -0500, Mike Frysinger wrote: On Thursday 08 March 2007, Kevin F. Quinn wrote: As we all know, setting LC_ALL and friends can cause all sorts of trouble in package builds. However, many users really appreciate being able to set it so that errors from the compiler etc are in their own language. we've fixed our documents so users should be setting LANG, not LC_ALL It occurs to me that during emerge, only LC_MESSAGES is actually useful for the user, to help interpret build errors. LC_COLLATE and the others don't give the user any benefit in the emerge process. So how about if LANG or LC_* are set, portage would set LC_MESSAGES and clear the rest? Is there any real advantage to the user having LC_* set apart from LC_MESSAGES? to answer the question directly, i think you're correct in that only LC_MESSAGES is a benefit to the user and screwing with the localization variables as suggested seems pretty sane hwever, ;) while i see the direction you're looking to go and the burdens you're looking to relieve, i think this just puts us back to the state that i disagree with ... namely that we shouldnt be ignoring these sort of problems, we should be fixing them Seems a forced ignore would fix them. (problem solved! next bug..) -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] allow people to disambiguate built_with_use in upgrade situations
On Tue, 2007-01-16 at 19:06 -0500, Mike Frysinger wrote: Diego is proposing a new flag to built_with_use to handle the corner case where you query a package that does not have the requested flag in IUSE built_with_use [--missing action] ... so in the case of version transitions, you can specify the action as either true, false, or die (only current option) seems like a cleaner solution than forcing what can be a rats nest of has_version checks -mike I'd agree. The built_with_use is a thorn in the side with the existing behavior. Adding --missing yes|no 0|1 would be nice. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] New emerge --mindeps option for exclusion of build time dependencies (bug #132355)
On Tue, 2006-07-11 at 22:32 -0700, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, The attached patch for bug #132355 [1] adds a --mindeps option for emerge that effectively allows build time dependencies to be excluded from dependency calculations involving binary and installed packages. With this patch, it's possible to remove all build time dependencies from a system with the command `emerge --depclean --mindeps`. When --mindeps is used to install packages, it causes build time dependencies to be excluded for binary packages and packages that are already installed. This patch will change the previous default behavior for `emerge --usepkg package list`, but if desired, the user will be able use --mindeps together with --usepkg. Are there any suggestions to improve on this idea or is it fine the way that it is? Please invert the logic so that rather than changing default behavior you add a new option choose the types of deps to include. I was in favor and thought we were going to do it after 2.1 and the 2006 release under the idea of the variable ACCEPT_DEPENDS export ACCEPT_DEPENDS=DEPEND RDEPEND PDEPEND emerge -K system Whatever we do in the end does not really matter as long as we don't change default expected behaviors. Zac [1] http://bugs.gentoo.org/show_bug.cgi?id=132355 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEtIlf/ejvha5XGaMRAo26AKCovCALx/VDIft6e+0lh+FI7IQsoQCg8o6M UW+dnXPwMe/tIje1A4RYqRs= =9uIv -END PGP SIGNATURE- -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [Fwd: [gentoo-dev] Portage-2.1 released]
This should of been sent to this list also. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux ---BeginMessage--- Portage-2.1 final is released, RELEASE-NOTES[1] NEWS[2] BUGS-FIXED[3] STABLIZING BUG[4] [1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup [2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup [3]http://bugs.gentoo.org/show_bug.cgi?id=115839 [4]http://bugs.gentoo.org/show_bug.cgi?id=136198 -- gentoo-dev@gentoo.org mailing list ---End Message---
Re: [gentoo-portage-dev] RPM build changes
On Fri, 2006-05-12 at 16:05 -0700, Nimish Pachapurkar wrote: Hello All, I have been fiddling with Portage for a few weeks now. Recently, I was trying to get the RPM creation with ebuild to work a little better. I noticed that currently emerge does not support building RPMs, but ebuild does. I have added some code to emerge that can build RPM for a package and all its dependencies. It will optionally merge the package to the system or just build an RPM. I am basically making this work very similar to the --buildpkg and --buildpkgonly options. I am using --buildrpm (-r) and --buildrpmonly (-R) options currently for these two tasks. However, if those two short options are reserved for some other purpose, I am fine with changing them. (If so, please suggest different short options). If this functionality is likely to be useful to other people also, I would love to submit a patch. I think I have somewhat older version of portage. Which version should I build the patch against, if I have to? 2.1 is in a feature freeze right now. Everybody is trying to tidy up existing functionality in preparation for 2006.1 But that would of otherwise been the branch of seen it committed to. probably best to give it a few weeks and revisit. rpm support however needs more than a few emerge switches. The existing package itself of rpm in the tree has a few problems and really needs a maintainer. Also portage's auto spec generation is on the side of far to basic to really be useful. A while ago a user Peter S. Mazinger [EMAIL PROTECTED] and myself discussed in semi detail a lot of the problems surrounding rpm support and later he sent me some patches that interpolated nicely with the existing rpm based distros. I mirrored those patches and they are all tagged with the names of the portage-rpm-*.patch http://dev.gentoo.org/~solar/patch_overlay/sys-apps/portage/ You may find some of those patches inspirational to your work. good luck. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] glsa implemented as a special set
On Mon, 2006-04-24 at 17:13 +0200, Marius Mauch wrote: On Mon, 24 Apr 2006 07:04:13 -0700 Brian [EMAIL PROTECTED] wrote: On Mon, 2006-24-04 at 14:20 +0200, Marius Mauch wrote: On Sun, 23 Apr 2006 08:55:58 -0700 Brian [EMAIL PROTECTED] wrote: I was thinking that /etc/portage/sets/glsa could be a symlink to set list in the current metadata/glsa directory of the portage tree. That file should be relatively easy to auto-generate from the existing glsa*.xml files there already. Perhaps a FEATURES=GLSA_SET would generate that file on completion of an emerge --sync I could also then put a GLSA field into porthole's package Summary view as well as a GLSA notebook page(s) to display the appropriate glsa?.xml file(s). Too complicated. First you currently need gentoolkit for glsa.py, and portage shouldn't depend on gentoolkit. I did not mean portage should and I din't want to depend on gentoolkit either. Not sure I understand your idea then, I was under the impression that `FEATURE=GLSA_SET emerge --sync` would create that file, is that not what you meant? Also you can't store system-specific files in the tree. Yeah, that was a bit of a thought evolution while I was typing. I realized after I hit send. At first I thought it could be included in the sync. Then thought it's only a duplication of the data already there, so why not generate it (save bandwidth), since the data will only change at sync time, just do it once then. Ehm, you couldn't include it in the sync as it's system specific. It would have to be generated locally, or you have to treat it special again (only update packages that are installed, don't install new packages). One could use the new postsync hook for doing this via glsa-check or a modified copy already. And finally using an intermediate file creates some additional issues (check for IO/FS problems, checking permissions, etc). Any reason you need a real file for this instead of just generating the list on the fly? I thought a smaller stripped down glsa.py module could generate the file at completion of the sync. Then no special code is needed internal in porthole beyond checking for set inclusion, atom matching, just a glsa_flag=True to ignore members that are not already installed. Once portage was able to handle sets, it would almost automatically be able to handle a glsa set as well. The only difference is not installing a set member that is not already installed. *Shrug*, generating the list dynamically shouldn't take more than 10 or 20 lines using glsa.py, basically it's pkg_list = [] glsa_list = [Glsa(x) for x in get_glsa_list(glsadir, glsaconfig)] for x in glsa_list: if x.isVulnerable(): pkg_list.extend(x.getMergelist()) plus some error handling. Add some dep_getkey() calls if you don't want the glsa resolver logic of minimal intrusion (might be problematic though). If you need a file interface wrap the list in a StringIO instance. It's really better to keep interdependencies to a minimum here, and when portage gets set support it will generate the glsa update list dynamically anyway, so portage wouldn't benefit from a file at all. Marius -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
On Mon, 2006-04-10 at 02:24 -0700, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, What do people think about adding userpriv and usersandox to make.globals FEATURES? I've been using these for a long time and haven't had any trouble with them. Are there any arguments against making them default? This is would qualify as core change. Please post this on the -dev ml. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEOiRf/ejvha5XGaMRAn+kAJ9ieh37OjEwTriDQt/xPnmMGqEPsQCg7qvf XEcYhyzdGSDBj8HtH8QYJzk= =ge1C -END PGP SIGNATURE- -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Thu, 2006-04-06 at 13:13 -0700, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I think the current quality level of the 2.1 branch is good enough to make it a release candidate. From my perspective, it seems like a waste of everyone's time to roll a 2.0.55 release when 2.1 is a perfectly good replacement (with lots of bug fixes relative to 2.0.54). I know there are probably some additional features that people would like to get into 2.1 before we make this transition. Despite this, I think that it's in everyone's best interest to retire the the 2.0.x branch as soon as possible so that it doesn't waste people's time. This transition doesn't necessarily mean that it's going to be a long time before some desired feature X is available in the stable version of portage. The next release after 2.1 (2.2 or whatever) doesn't necessarily have to be too far off in the future. So, I'd like to create 2.1 branch that is closed to mostly anything except regression fixes and release it as portage-2.1_rc1 this Saturday. We can continue to do ~arch releases of the development branch (2.2 or whatever it becomes) every 2 weeks. Does now seem like a good time for this transition? Your feedback would be appreciated. If this has been repeated elsewhere than sorry for the re-post. The resolver still needs a bit of work before it's ready. Handling of the || () in ROOT!=/ via the -K option is not in that good of shape in 2.1_NXX and can't really be used. Till that's addressed 2.1(re-ping jason) in my eyes absolutely should not even be considered for any rc status. Other than that I'm quite pleased with many aspects of 2.1 -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
On Fri, 2006-04-07 at 21:06 +0900, Jason Stubbs wrote:
On Friday 07 April 2006 20:54, Ned Ludd wrote:
Handling of the || () in ROOT!=/ via the -K option is not in that
good of shape in 2.1_NXX and can't really be used. Till that's
addressed 2.1(re-ping jason) in my eyes absolutely should
not even be considered for any rc status.
Can you refresh my memory on what the issue is here?
Example off the top of my head:
FEATURES=buildpkg ROOT=/ emerge gcc
rm -rf /dev/shm/foo
ROOT=/dev/shm/foo emerge gcc -pvK
Notice how it selects the incorrect deps?
IE: eselect cuz it's the first listed dep in the || ( ) vs the
gcc-config
+ When you already have a copy of gcc-config installed on / and in
.tbz2 format in ${PKGDIR}/All and no eselect anywhere.
Depstring: || ( app-admin/eselect-compiler
=sys-devel/gcc-config-1.3.12-r4 ) ...
Candidates: ['app-admin/eselect-compiler', '=sys-libs/ncurses-5.2-r2']
Then compare with
ROOT=/dev/shm/foo emerge -pvk gcc
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Short question
On Sat, 2006-03-18 at 20:22 +0200, Rumen Yotov wrote: On Saturday 18 March 2006 20:03, tvali wrote: Is /usr/lib/portage/pym dir and /usr/bin/emerge files together the whole portage (excluding package tree)? Is there any portage code outside those ... Hi, Install app-portage/portage-utils and then run: #qlist portage btw that would be qlist -e portage. Without the -e portage* would be matched and thus portage-utils itself would be in the output. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Enabling RSYNC_OPTIONS to be set in make.conf
On Fri, 2006-03-10 at 14:38 -0600, Robert Larson wrote: Hello list, I am needing to allow for further configuration of rsync for syncing portage. The addition of RSYNC_OPTIONS in make.conf could alleviate this need for me, but what do you guys think? [snip] I think genone has a more complete patch for this already. If he has not committed it already I'm sure he will soon. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Mon, 2006-03-06 at 09:21 +0100, Kevin F. Quinn (Gentoo) wrote: On Sun, 5 Mar 2006 20:46:25 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 05 March 2006 19:48, Kevin F. Quinn (Gentoo) wrote: This could be done via the profiles, perhaps - package.qa, something like package.mask/use/keywords: i hate such things ... imo this information should stay in the ebuild and nowhere else ... I was thinking that the data would be owned by the QA team rather than the package maintainers. I appreciate your pov, however. That is a good point. Sadly I'd say I do not trust a large portion of our maintainers to do the right thing and not abuse the variable in the long run simply because they do not know how to fix a pkg properly. vs say exporting env variables all over the place (bloating ebuilds even more) a single file does offer quite a few advantages. In addition a single file could be directly parsed by the scanelf util and be simply told to ignore the additional QA checks using fnmatch() for paths or so. It would also provide an easy overview of whats messed up in the tree. shrug... [snip] Heh - here's another idea for you to hate: QA_OVERRIDE=EXECSTACK=... x86? ( TEXTRELS=... ) /me hates that also. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Sun, 2006-03-05 at 20:46 -0500, Mike Frysinger wrote: [snip] be trivial to expand the support like: QA_TEXTRELS=... # for all arches QA_TEXTRELS_arch=... # for just one arch so in the case of slmodem: QA_EXEC_STACK=usr/sbin/slmodemd in the case of some other package that only has issues on x86: QA_EXEC_STACK_x86=some/foo this thread was about the naming convention :P does QA_EXEC_STACK and QA_TEXTRELS work for people ? -mike I'd prefer EXECSTACK as one word to follow suit with ld, but otherwise works for me. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Mon, 2005-12-05 at 23:06 +0900, Jason Stubbs wrote: Okay, new suggestion. Postpone the cache rewrite from above. Have only the minimal mods necessary to fix the PORT_LOGDIR/tee bug. Include the other two as is. That would be 2.0.54 as per the attached patch. Get that out soon and get trunk out masked at around the same time. As soon as 2.0.54 goes stable put trunk into ~arch. However, instead of ~arch meaning regression fixes only we could just limit it to minor changes only (ie. no big refactorings, rewrites or similar high risk changes) until it is time to stable it. I think it would be wise to reconsider the cache fixes. I know you have been away from irc for a while now and have missed the daily events, but most of the people we have interacted with are expecting the cache updates in .54 (alot of people complaining about the hanging at 50%) The code has been pretty well tested and seems safe on the surface. I think ferringb's testing has shown that the cache updates use about 14M of ram where the existing code (as of .52.x) uses about 80M of ram. -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] vdb size reduction techniques
2 other vdb size reductions can be done, with maybe a 3rd in the distant future. If you cat your /var/db/pkg/sys-devel/gcc*/IUSE you will notice that we have several inherited duplicates in it. To reduce wasted bytes there we can simply tr,sort,uniq them from bash. The for the vdb USE file I'm thinking we only need to save the USE flags that correspond to the IUSE flags when the package was merged. These smaller files should directly equate to portage speed ups when importing as it's less runtime reprocessing that has to be done. Anybody see any reason not to make the 2 above changes for .54 ? -- Maybe way future? -- We could take it a step further even and stop using a single file for just about every vdb entry excluding the env.bz2, CONTENTS and COUNTER and anything else that needs to be multiline. CFLAGS= RDEPEND= DEPEND= IUSE= USE= etc.. More or less treating it in pretty much the same manor as metadata cache entries. I see such a method as having mostly advantages and maybe 1 disadvantage. An initial 'import portage' could be slower unless PROVIDE,USE were the first two entries and the file was parsed and does not continue to read the rest of the file. ie no grabfile. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 02:05, Ned Ludd wrote:
On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 00:31, Ned Ludd wrote:
* post_sync action hook (.53/.54 )
* VDB prevention of single byte NULL entries being created. ( .54 )
Doable for .54.
Yeah and from the sounds of it we may want more than 1 set of postsync
hooks or the addition of a postsync.d/
(dev thread on getting vital info to users)
Heh.. that was my suggestion. ;)
Yeah it seems doable for .53 but if you want to wait till .54 or
a .53-rXX thats fine. I'd prefer to see it in .53 unless
that's going out the door today.
* new prepstrip offering splitdebug ( .53/.54 )
Need to work out exactly what will be offered when on this one, but at
the earliest it will be .54. Perhaps go with your patch for .54 and leave
Olivier's fancy bits for later?
I can only assure you the code I wrote will function properly.
So that's the only thing I'm trying/willing to push myself.
As long as he has those [ -x checks ] his code should be harmless,
but I don't see the advantage in it over building with -g3.
There are a few other questions too... Should
the default be to generate external debug info?
I think the security team would say yes they want it by default and
would be willing (taviso) to write a proper debug-HOWTO.xml for gentoo.
I think ferringb would say make it FEATURES=splitdebug if
it's going in midstream.
It does add some size which would make peoples $ROOT's a little bit
bigger. But from mine and other peoples testing it's pretty damn
minimal. I think Halcy0n @ gentoo said after doing an -e world he ended
up with only 18M of split debug info
I'm also fond of split packaging of debug info also (but I'm not going
to push for that till I find a more elegant way)
[EMAIL PROTECTED] debug $ qsize pax-utils
app-misc/pax-utils-debug-0.1.4-r0: 3 files, 5 non-files, 16.27 KB
app-misc/pax-utils-0.1.4: 6 files, 6 non-files, 102.485 KB
Perhaps we should get input from gentoo-dev ml ?
Sounds good for pretty much all aspects of split debug (other than the
capability itself).
Should generating internal
debug info still be offered?
When FEATURES=nostrip is enabled we should not split off
any debug info or touch the executable.
FEATURES=splitdebug|stripdebug and do nothing if neither is set?
If feature based it seems logical to me to have it as either
splitdebug || nosplitdebug
I know some people hate no* functions or rather they hate no* USE
flags. But it would seem fitting if we decided to make it a default vs
sticking in splitdebug in all profiles.
The feeling I get in general is that some devs want it by default to
make helping users who don't really know how to debug give us the info
we need without much hassles.
stripdebug I'm not sure what you envision with that name.
* flattened vdb {P,R,}DEPEND (.54 )
I might be wrong but I can't really see this being done cleanly. At best,
only USE flags could be gotten rid of which would still leave || ()
constructs. This leads me to question of what use it would really be. If
it can only do a half-arsed job and in a messy way at that I'd personally
prefer it to be done later on.
It will indeed still leave you with || ( foo bar ) or =cpv which you
can be parsed just fine. Yeah it would be nice if it could be reduced
more but later on or now I don't see how it can be reduced anymore than
to the requirements that the ebuild requested.
Again, if it can be done cleanly code-wise no issues with resolving the USE
flags out.
Should only be a few lines of code. (I hope)
Something like hand off the env varable from dyn_compile() in ebuild.sh
to python and python passes it back to ebuild.sh in the next phase for
dyn_install() which gets recorded flattened
If it's not doable then I'll just go for a simple cosmetic patch to
remove newlines and extra spaces.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 00:31, Ned Ludd wrote:
On Sat, 2005-11-26 at 00:01 +0900, Jason Stubbs wrote:
Hi all,
I don't think there's really anything else that can be done for 2.0.53 so
am thinking that we should probably push _rc7 + docs out and let the arch
teams mark it stable when they're ready (or stick with 2.0.51.22-r3 if it
pleaseth them).
[snip]
There's a few things listed on the new
(still unreleased?) project index and I'm looking to get the dependency
stuff refactored and moved out of emerge.. What are the shortterm goals?
For me my short term goals are to see these things happen
* pax-utils depends ( .53 )
* seeing CDEPEND stop being created for the VDB ( .53 )
Definitely doable.
* post_sync action hook (.53/.54 )
* VDB prevention of single byte NULL entries being created. ( .54 )
Doable for .54.
Yeah and from the sounds of it we may want more than 1 set of postsync
hooks or the addition of a postsync.d/
(dev thread on getting vital info to users)
* new prepstrip offering splitdebug ( .53/.54 )
Need to work out exactly what will be offered when on this one, but at the
earliest it will be .54. Perhaps go with your patch for .54 and leave
Olivier's fancy bits for later?
I can only assure you the code I wrote will function properly.
So that's the only thing I'm trying/willing to push myself.
As long as he has those [ -x checks ] his code should be harmless,
but I don't see the advantage in it over building with -g3.
There are a few other questions too... Should
the default be to generate external debug info?
I think the security team would say yes they want it by default and
would be willing (taviso) to write a proper debug-HOWTO.xml for gentoo.
I think ferringb would say make it FEATURES=splitdebug if
it's going in midstream.
It does add some size which would make peoples $ROOT's a little bit
bigger. But from mine and other peoples testing it's pretty damn
minimal. I think Halcy0n @ gentoo said after doing an -e world he ended
up with only 18M of split debug info
I'm also fond of split packaging of debug info also (but I'm not going
to push for that till I find a more elegant way)
[EMAIL PROTECTED] debug $ qsize pax-utils
app-misc/pax-utils-debug-0.1.4-r0: 3 files, 5 non-files, 16.27 KB
app-misc/pax-utils-0.1.4: 6 files, 6 non-files, 102.485 KB
Perhaps we should get input from gentoo-dev ml ?
Should generating internal
debug info still be offered?
When FEATURES=nostrip is enabled we should not split off
any debug info or touch the executable.
What platforms is it supported on?..
Everywhere ELF is a standard.
* misc cleanups of dyn_install (.54 )
Need more info.
This is just something I want todo for my own sanity,
ie break parts of our existing dyn_install() out
into /usr/lib/portage/bin/ scripts.
The current function is about 209 lines of code and I
can see it growing even more.
* flattened vdb {P,R,}DEPEND (.54 )
I might be wrong but I can't really see this being done cleanly. At best,
only
USE flags could be gotten rid of which would still leave || () constructs.
This leads me to question of what use it would really be. If it can only do a
half-arsed job and in a messy way at that I'd personally prefer it to be done
later on.
It will indeed still leave you with || ( foo bar ) or =cpv which you
can be parsed just fine. Yeah it would be nice if it could be reduced
more but later on or now I don't see how it can be reduced anymore than
to the requirements that the ebuild requested. One big advantage for me
here is that virtuals would be resolved.
This will probably lead to an overall reduction in size of the VDB.
* introduction of RRDEPEND to the VDB ( .54 )
What is this again?
Ok I talked a little bit about this on this list the other day and a few
months ago with you on #-portage.
man
RRDEPEND
This entry is automatically created by portage. It contains a
list of reverse dependencies that is achieved by resolving the
DT_NEEDED entries of an ELF executable.
/man
Justification
Programs such as revdep-rebuild, verify-rdepend would be able to make
immediate use. A little bit of a longer term goal is to see portage gain
the ability to request to only use RRDEPEND entries to be used for
depgraph creation for use with embedded/mimimal systems.
ROOT=/dev/shm/minimal emerge -KO --deps=RRDEPEND pkgfoo
RRDEPEND will need to exist due to the RDEPEND explosion and lack of a
clear definition when it was first introduced to portage.
The advantage from where I'm sitting is that devs don't really have a
chance to make mistakes with R/DEPEND handling and people who are
attempting to stage $ROOT can get exactly what they are after in the
embedded world.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 2005-11-25 at 21:00 +, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 12:05:57 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | Programs such as revdep-rebuild, verify-rdepend would be able to make | immediate use. A little bit of a longer term goal is to see portage | gain the ability to request to only use RRDEPEND entries to be used | for depgraph creation for use with embedded/mimimal systems. How will that work for packages that have a runtime dependency upon a text file supplied by a different package? text files which are true runtime deps belong in RDEPEND. Clearly c++ templates are beyond the scope of the what RRDEPEND can provide. I could be wrong but I don't think those c++ templates are anything revdep-rebuild or verify-rdepends handle any differently. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 2005-11-25 at 22:02 +, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 16:41:19 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | On Fri, 2005-11-25 at 21:00 +, Ciaran McCreesh wrote: | How will that work for packages that have a runtime dependency upon | a text file supplied by a different package? | | text files which are true runtime deps belong in RDEPEND. Ok. So embedded tools which rely upon RRDEPEND for runtime dependencies will end up producing incomplete installs? Yeah that's what we want, We intend to create tools that leave systems broken. You want to be the first tester? Please take your spin of things off of this and look at it for what it is. Your not going to use a feature for something unless it's suited for the job at hand. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 2005-11-25 at 23:10 +, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 17:49:50 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | Yeah that's what we want, We intend to create tools that leave systems | broken. You want to be the first tester? Please take your spin of | things off of this and look at it for what it is. Your not going to | use a feature for something unless it's suited for the job at hand. So why not create a better feature? What the hell are you talking about? No tools have even been created yet. Nobody builds tools before the framework is in place. The ability to make use of RRDEPEND as I've pointed out by verify-rdepend and revdep-rebuild could be pretty much immediate. The ability to control what level of depends a user wants in his/her depgraph is up to the user. The way I envision it you could just as easliy do ROOT=/dev/shm/minimal emerge -KO --deps=RDEPEND:DEPEND:PDEPEND pkgfoo To yield the same results as portage by default. In general I'd suggest that you not attempt to make use of features that don't suit your needs. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Fri, 2005-11-25 at 23:53 +, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 18:48:41 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | What the hell are you talking about? No tools have even been | created yet. Nobody builds tools before the framework is in place. The | ability to make use of RRDEPEND as I've pointed out by verify-rdepend | and revdep-rebuild could be pretty much immediate. The ability to | control what level of depends a user wants in his/her depgraph is up | to the user. The way I envision it you could just as easliy do | ROOT=/dev/shm/minimal emerge -KO --deps=RDEPEND:DEPEND:PDEPEND | pkgfoo To yield the same results as portage by default. In general | I'd suggest that you not attempt to make use of features that don't | suit your needs. Why introduce a feature which is crippled? It would be almost as easy to allow ebuilds to mess with their 'real' runtime dependency value as appropriate rather than forcing an incorrect auto-generated list onto everyone. Please go back to trolling on dev We are trying to get work done here and solve real problems. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote: [snip stuff] Need to head to bed now. Will respond to other parts tomorrow. A little bit of a longer term goal is to see portage gain the ability to request to only use RRDEPEND entries to be used for depgraph creation for use with embedded/mimimal systems. ROOT=/dev/shm/minimal emerge -KO --deps=RRDEPEND pkgfoo This is definitely not something that could be done in any of 2.x unless it's done as an external tool (which would not be so hard as order doesn't matter with binary packages). I'm not sure that I like the idea of selectively ignoring *DEPEND in 3.x anyway - by that stage sanity checking should be 100% but selective *DEPENDs will either poke huge holes through it or make a huge mess. Either way, it's not a tomorrow thing so discussion should probably wait until it's more viable. That's fine I'm not ready to focus on --deps= right away. As stated it's a longer term goal and I would also prefer to discuss it at a later time. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] ebuild path/to/ebuild rpm does not work, spec files aren't generated
On Thu, 2005-10-27 at 08:26 +0900, Jason Stubbs wrote: On Thursday 27 October 2005 08:04, m h wrote: Hmmm, then I must be missing where the spec file gets generated, because there is no code in ebuild.py that does it... ebuild.py..? Are you using 2.1.0_alphayymmdd? You may very well be the only person trying to use rpm with that version. Try dropping back to 2.0.53 and see what happens there. If I may chime in. Our rpm support is a tad incomplete currently. I've got some patches which overhaul the rpm handling in portage that come from Peter S. Mazinger so portage can properly generate usable rpm's without requiring user interaction etc. It's $FEATURE based and I've got about 135 packages built from it in my local tree. I think Peter has some 500+ working ones. http://dev.gentoo.org/~solar/patch_overlay/sys-apps/portage/ portage-*rpm*.patch The package rpm itself in portage needs some love, which is why these really patches have not been submitted to bugzilla/portage-dev yet. Before this support can really work properly we have to find a maintainer for the rpm package and get him/her the patches to allow us to have /usr/src/gentoo and gentoo-like configurations. Originally only redhat/mandrake/suse/conectiva compatible packages were supported. We have some PIC corrections, corrections from openpkg, allow to bootstrap into packaging, and better handling of shared/debug/rpc allow to use newer beecrypt and system provided popt corrections from openpkg. Peter anything I'm forgetting to mention about this? You have to subscribe to the mailing list to reply. -- Ned Ludd [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
