Re: [gentoo-dev] Manifest2 decision delayed
Ciaran McCreesh wrote: On Fri, 10 Feb 2006 10:14:26 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: | Interesting, yes... but ebuilds are read by humans and it is necessary | to be comprehensible a lot more than the Manifest files are. Sure. But the comparison would show whether or not it's going to make a substantial difference. And if it does, there're other things that can be done in the Manifest file that'll save a whole load of space too (e.g. using $ to represent $PN, ! to represent files/, * to represent ChangeLog and so on, since these characters aren't allowed in any filename in the tree). When you have thousands of small files (1-4 blocks), the space saved by removing all unnecessary whitespaces is minimal at best. Minimizing the number of files is another story. Unifying manifests with digest files will save a considerably amount of disk space. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Request for Comment
(I think it would be better if you could post the text on the list, so people can easier cite the paragraphs they are referring to.) I cite one situation which has actually led to system destruction: I was in need of a certain version of a library. A the moment I installed it initially, this version was keyword masked for my architecture, since it was not thoroughly tested. It worked perfectly anyway. Since it was without issues, it became officially unmasked some time later and another version was introduced, which was keyword masked because it didn't work at all on my architecture. This one could be compiled, but really didn't work at all. Since I didn't observe the new version introductions all the time, a slightly careless world update gave me that version and left all programs depending on the library in a non-working state. After all it was my fault, but on a resonably maintained system you will always have a number of manually unmasked ebuilds, and you can't monitor them all the time. This is why you should use exact versions in p.mask and p.unmask. If you do that you only get the minimum of masked packages, leading to minimal borkage. Now, over to the GLEP draft.. You make some very dangerous (partly wrong) assumptions in your GLEP. First of all, there's the assumption that we have the capacity to maintain such a fine graded masking scheme. We are currently mainly distinguishing between testing ~arch and stable arch. I can only speak for AMD64, but we have a currently ~100 packages that wait to go into the ~amd64 tree, 54 of them for longer than 30 days. Beside that, we have about 120 packages waiting to go into the stable tree. Now, if you'd increase the number of masking stages from two to 10, I can guarantee that this masking scheme would get completely useless. But the far more critical assumption you make is this one: You assume that once a package has been marked stable, it keeps beeing stable. You simply can't treat every package individually. A package marked stable back in 2004 with a status level -5 should be considered ultimatively stable if I understand your proposal right. But then GCC 3.4 is marked stable too, and, oh, look, it doesn't even compile!? Things depend on each other, in a very complex fashion. Whenever some behaviour in one package is changed, it is likely to break another one. Instead of giving us 10 different status levels, show us a way to avoid such problems in general. Part of the assumption above is also the fact that these keywords do not consider the profile the user is using. A package might work great for one profile but terribly break for another (deprecated) one. You can apply the same idea to eclasses. Basically it all bails down to this: Give me 10 environments and I give you 10 different ways to break the package. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: GLEP 47: Creating 'safe' environment variables
Grobian posted [EMAIL PROTECTED], excerpted below, on Fri, 10 Feb 2006 19:39:38 +0100: I assume you meant to replace 'tuple' with 'segment'. First of all, I might be biased, as for me everything is a binary association table. However, I don't think a segment is the same in this case. 'part' would be better, perhaps. In the end I think GLEPs are targetted at programmers: those of Gentoo, as such it is not targetted at a broad (and generic) audience at all. I prefer to stick with 'tuples' for now. Yes, I did. I ended up looking it up. I found two things. One, Component, as in 1-component, 2-component, and 4-component, appeared to be in agreement with both the single definition at FOLDOC and the dual comp-sci definitions at Wikipedia, as both sources used it, so if one were to go that way, component would seem technically acceptable (more so than my original choice, segment). However, I also noted that the Wikipedia entry said any positive number and legitimized the N-tuple usage as well, so yes, it /was/ just me, in this case, as 1-tuple would appear to be narrowly within the definition, at least on Wikipedia, for what it's worth. I'd personally still argue for component as that makes the GLEP more accessible to ordinary users, but you are correct in the primary targeting and apparently at least narrowly so in definition, and it's not my effort, so I get overruled. g No further reservations, at this point, and due to the backward compatibility, this GLEP would seem much more workable than the 4-tuple GLEP, so good idea! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for Comment
Klaus-J. Wolf wrote: Hi, I am new to this list, but I am not new to Gentoo. Would you please discuss a GLEP draft, which I believe it might improve the usability of Gentoo? Text at: http://www.seismic.de/gentoo/gentoo_mask_proposal.html Technical details still missing... Ignoring the huge maintenance issues already stated there are also technical reasons speaking against this. First adding another file in every package dir would bloat the tree considerably (estimate about 50 MB diskspace on normal filesystems). Second separting the metadata from the ebuilds has major implications on portage (need a new parser, API changes in core functions, complete change of semantics). And finally of course there is this minor issue called transition. So short version: no chance. Marius -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Manifest2 decision delayed
Alin Nastac posted [EMAIL PROTECTED], excerpted below, on Sat, 11 Feb 2006 11:38:05 +0200: When you have thousands of small files (1-4 blocks), the space saved by removing all unnecessary whitespaces is minimal at best. Of course, that depends on the filesystemm used... . -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Manifest2 decision delayed
On Sat, Feb 11, 2006 at 11:38:05AM +0200, Alin Nastac [EMAIL PROTECTED] wrote: When you have thousands of small files (1-4 blocks), the space saved by removing all unnecessary whitespaces is minimal at best. Minimizing the number of files is another story. Unifying manifests with digest files will save a considerably amount of disk space. not to mention inodes. Thats one of my pet-hates about the tree' size. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpMi8VmuXsjM.pgp Description: PGP signature
[gentoo-dev] Re: Re: Request for Comment
John Mylchreest posted [EMAIL PROTECTED], excerpted below, on Sat, 11 Feb 2006 17:02:58 +: Duncan, you make some valid points but for the sake of ease for the rest of us, could you please try condense the mails down from several pages? :) I've been proud of myself, even managing a couple one-liners, lately. =8^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Request for Comment
On Sat, Feb 11, 2006 at 11:09:07AM -0700, Duncan [EMAIL PROTECTED] wrote: Duncan, you make some valid points but for the sake of ease for the rest of us, could you please try condense the mails down from several pages? :) I've been proud of myself, even managing a couple one-liners, lately. =8^) Keep up the excellent work ;) -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpIK95zcZ8h5.pgp Description: PGP signature
[gentoo-dev] gtk2 use flag deprecation = bashing my head against the wall
Reading the last two comments (Bug 106560) from devs who removed them from CC again makes my cry out loud in desperation. People, *please* read the two attachments I've posted there, and think again before stating something about fixed months ago etc. etc. :-( http://bugs.gentoo.org/show_bug.cgi?id=106560 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpnufdngyRGw.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On 11-02-2006 20:05:58 +, Ciaran McCreesh wrote: On Sat, 11 Feb 2006 08:28:34 +0100 Grobian [EMAIL PROTECTED] wrote: | kfreebsd-gnu is, in effect, one example you're using already. You'd | have x86 as the arch, FreeBSD as the kernel and GNU as the userland. | | Yes, but you're actually mixing two things here now. The right hand | side of the 2-tuple is not a kernel or userland, it is an OS, which | includes this in itself. Mm. I'm not convinced that that justifies creating weird codes for the weird cases... Ok. If we're on the same wave length here, then I think the real question is here whether we do allow hyphens to be in the os part or not. If yes, the part till the first hyphen is the arch, and everything from the hyphen (exclusive) till the end of string is the os part. If no, an 'escape' method must be defined for the os part. In both cases it is necessary to state that the arch cannot contain hyphens in it, and if such restriction is defined, it might be handy to immediately add spaces and the like to the list. -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Sat, 11 Feb 2006 22:28:43 +0100 Grobian [EMAIL PROTECTED] wrote: | Ok. If we're on the same wave length here, then I think the real | question is here whether we do allow hyphens to be in the os part or | not. If yes, the part till the first hyphen is the arch, and | everything from the hyphen (exclusive) till the end of string is the | os part. If no, an 'escape' method must be defined for the os part. | In both cases it is necessary to state that the arch cannot contain | hyphens in it, and if such restriction is defined, it might be handy | to immediately add spaces and the like to the list. Standard practice is to define what's allowed, not what's forbidden, and the usual range is a subset of a-zA-Z0-9_+:- . -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] check-reqs conditionals
For those of you who don't know, check-reqs is an eclass that is
occasionally used by a few packages that have ludicrously high build
requirements. Typical examples have included anything using Haskell (the
programming language with built-in memory leaks!) and certain C++
template metaprogamming voodoo.
Currently it just exports a single function that will warn (or die,
based upon user preference) if the build requirements aren't met. There
has been a request for a clean way of handling packages that can be
built in two different ways that give the same end result (typical
example is use of a really slow but low memory requiring algorithm vs a
fast but memory intensive algorithm when building data tables).
How does something like the attached look? (Yes, it's using old-school
[ rather than [[, since the rest of the eclass is written that way. I
might switch the whole thing over at some point.)
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
Index: check-reqs.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v
retrieving revision 1.4
diff -u -r1.4 check-reqs.eclass
--- check-reqs.eclass 6 Jul 2005 20:23:20 - 1.4
+++ check-reqs.eclass 11 Feb 2006 22:35:14 -
@@ -39,6 +39,10 @@
# check_reqs
# }
#
+# Alternatively, the check_reqs_conditional function can be used to carry out
+# alternate actions (e.g. using a much slower but far less memory intensive
+# build option that gives the same end result).
+#
# You should *not* override the user's CHECKREQS_ACTION setting, nor should you
# attempt to provide a value if it is unset. Note that the environment variables
# are used rather than parameters for a few reasons:
@@ -84,6 +88,23 @@
fi
}
+check_reqs_conditional() {
+ [ -n $1 ] die Usage: check_reqs
+
+ export CHECKREQS_NEED_SLEEP= CHECKREQS_NEED_DIE=
+ if [ $CHECKREQS_ACTION != ignore ] ; then
+ [ -n $CHECKREQS_MEMORY ] check_build_memory
+ [ -n $CHECKREQS_DISK_BUILD ] check_build_disk \
+ ${PORTAGE_TMPDIR} \${PORTAGE_TMPDIR} ${CHECKREQS_DISK_BUILD}
+ [ -n $CHECKREQS_DISK_USR ] check_build_disk \
+ ${ROOT}/usr \${ROOT}/usr ${CHECKREQS_DISK_USR}
+ [ -n $CHECKREQS_DISK_VAR ] check_build_disk \
+ ${ROOT}/var \${ROOT}/var ${CHECKREQS_DISK_VAR}
+ fi
+
+ [ -z ${CHECKREQS_NEED_SLEEP} ] [ -z ${CHECKREQS_NEED_DIE} ]
+}
+
# internal use only!
check_build_memory() {
[ -n $1 ] die Usage: check_build_memory
signature.asc
Description: PGP signature
Re: [gentoo-dev] Request for Comment
Klaus-J. Wolf wrote: http://www.seismic.de/gentoo/gentoo_mask_proposal.html * Manually keyword unmasking an ebuild, automatically means unmasking the last one in the line of masked versions. No. Use the = to unmask a specific version only. For example: =sys-apps/findutils-4.2.25 ~x86 Benno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for Comment
On Sun, 12 Feb 2006 00:11:07 +0100 Benno Schulenberg [EMAIL PROTECTED] wrote: | Klaus-J. Wolf wrote: | http://www.seismic.de/gentoo/gentoo_mask_proposal.html | |* Manually keyword unmasking an ebuild, automatically means | unmasking the last one in the line of masked versions. | | No. Use the = to unmask a specific version only. For example: | | =sys-apps/findutils-4.2.25 ~x86 Usually better to use ~, so that you pick up any revbumps. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] eselect 1.0 is out
On Sunday 12 February 2006 02:09, Ciaran McCreesh wrote: On Sun, 12 Feb 2006 01:38:53 +0200 Eldad Zack [EMAIL PROTECTED] wrote: | Is this a quirk or intentional: | | # eselect kernel show | Current kernel symlink: | linux-2.6.14.3/ | | (notice the trailing slash there) Mmm. What's your readlink? sys-apps/coreutils 5.2.1-r7 -- Eldad Zack [EMAIL PROTECTED] Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93 pgpHZObnVxC6a.pgp Description: PGP signature
Re: [gentoo-dev] eselect 1.0 is out
On Sun, 12 Feb 2006 02:27:33 +0200 Eldad Zack [EMAIL PROTECTED] wrote: | Mmm. What's your readlink? | | sys-apps/coreutils 5.2.1-r7 Looks like it depends upon how ln -s was invoked as to what readlink gives. Guess we'll have to work around that in a couple of places... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Last rites for net-libs/libpcap-ringbuffer
If there aren't any objections, we (netmon herd) will hardmask this package in a week and delete it one week later. Removing is due to lack of required features for some popular apps and bug #117898. With this removal we also want to wipe out the virtual/libpcap. So if any of your ebuilds uses it, change it to net-libs/libpcap instead. We'll do this on our own if there are any ones left in two weeks to avoid tree breakage. Markus -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites for net-libs/libpcap-ringbuffer
If there aren't any objections, we (netmon herd) will hardmask this package in a week and delete it one week later. Removing is due to lack of required features for some popular apps and bug #117898. With this removal we also want to wipe out the virtual/libpcap. So if any of your ebuilds uses it, change it to net-libs/libpcap instead. We'll do this on our own if there are any ones left in two weeks to avoid tree breakage. Markus -- gentoo-dev@gentoo.org mailing list
