Re: [gentoo-dev] Re: udev and /usr
On Friday, September 16, 2011 06:06:35 PM Duncan wrote: > Joost Roeleveld posted on Fri, 16 Sep 2011 10:36:27 +0200 as excerpted: > > I agree, I just used this example to explain that it shouldn't be > > necessary to force an initramfs on all users just because there is a > > small group who wants to have an extreme setup. > > Careful with the "extreme". As you no doubt realize by now, the udev > folks apparently consider anyone wanting a separate /usr but not an initr* > "extreme". That'd certainly apply double if said admin (since no simple > "user" cares about such stuff, in this view) had /usr on lvm. Yes, I've noticed that. Except that Redhat and Centos use LVM by default. Which will also mean that "simple users" also end up using LVM. Then again, they also end up with an initr* and a generic kernel for everything under the sun. I haven't properly looked at the kernel-configs from redhat lately, but I don't think they include all the possible hardware options be default? -- Joost
[gentoo-dev] Re: x32 fun pants
Markos Chandras posted on Fri, 16 Sep 2011 21:25:07 +0300 as excerpted:
>> that would be ideal, and drop "amd64" in the process: x86/x86_64/
>> -mike
>
> Ok so we will probably have the following multilib options
>
> * x86(ABI=x86_32{/lib}) + amd64(ABI=x86_64{lib64/}) +
> x32(ABI=x32{/libx32})
> * x86/amd64 ( what we already have in amd64 multilib )
This one would probably be x86/x86_64 , as Mike said drop amd64.
(Tho I much prefer amd64, or if it's changed, something else without a _,
which is hard to type, at least on the US/qwerty layout, requiring both
hands to get the shift, and two rows up plus over to get the _, amd64
works quite nicely in that regard.)
> * x86/x32
>
> and
>
> * x86 (no multilib for 32-bit processors ) ( what we already have in x86
> profile )
Don't forget current amd64/no-multilib. I guess that's be
* x86/x86_64/no-multilb
(Tho again, I'd prefer keeping amd64, for x86/amd64/no-multilib.)
And presumably there's also be
* x86/x32/no-multilib
--
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
Re: [gentoo-dev] A big thanks to Matt Turner for his hard work on Gentoo/MIPS
Hi, > Thanks Matt! Thanks, too! :) I've used MIPS before, and might set up an old octane again...so thanks for your effort! :) Greetings, Craig
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On 09/15/2011 05:20 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2011-09-16 01:54:44 Brian Harring napisał(a):
>> On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar
>> Arahesis wrote:
>>> 2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
On Thu, 15 Sep 2011 09:35:21 +0200
Michał Górny wrote:
> Could you point me to at least a single program not supporting dots
> in useflags? My quick check shows that all PMs handle them well, quse
> and euse as well.
Hrm, it's rather disappointing that they're accepted everywhere. That
really shouldn't happen... My excuse for Paludis is that I never quite
got around to passing in additional flags to validation of names, and
dots are legal in exheres-0
>>>
>>> There is no reason for Gentoo to be worse than Exherbo and not allow dots
>>> in USE flags.
>>
>> Seriously Arfrever, drop the rhetoric here, and go fix the profile
>> compatibility issue.
>
> I suggest to support files with "-${EAPI}" suffix.
> Examples:
> profiles/package.mask-5
> profiles/use.desc-5
> profiles/base/package.mask-5
> profiles/base/package.use-5
> profiles/base/package.use.force-5
> profiles/base/package.use.mask-5
> profiles/base/use.force-5
> profiles/base/use.mask-5
> profiles/desc/python_abis.desc-5
>
I'd prefer not to use separate files per eapi, since that effectively
gives you multiple profiles that behave differently depending on the
supported EAPI of the package manager.
As an alternative, I suggest to use the 'eapi' file to specify the EAPI
for all files in the directory. If you want to roll out EAPI 5 profiles
sooner, then you can fork a new base profile that only supports EAPI 5
or later, and base new profiles off of that. Bumping the EAPI of the
root profiles/eapi file would be a different matter, since it applies to
the whole repository. If you want to version bump that repository-level
EAPI, then you need to wait until at least 6 months after supporting
package managers have been available in stable.
--
Thanks,
Zac
Re: [gentoo-dev] new `usex` helper
On Fri, Sep 16, 2011 at 07:30:14AM -0500, Donnie Berkholz wrote: > On 02:06 Fri 16 Sep , Brian Harring wrote: > > Specious argument; the point of controllable stacking was to avoid the > > issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds > > (which may not support those modified eclasses) via the old > > PORTDIR_OVERLAY behaviour. This is why multiple repositories have > > layout.conf master definitions- to explicitly mark that they > > require/consume a seperate repo. > > So let me get this straight — instead, you want overlay users to > maintain a copy of every eclass they use, which will almost > automatically become outdated and stale because it won't track the > gentoo-x86 version? Where did I say that? layout.conf exists to allow repo's to explicitly state what they need- this means we can have individual overlay stacks, instead of having gentoo-x86, overlay1, overlay2, overlay3, with that as a single stack (including eclass lookup), it can be broken out as individual stacks. This limits the eclass affect for a repo to just what is explicitly configured. This is a good thing. This is controllable in addition. What I said from the getgo and you're missing is that pushing EAPI implementation into the tree and ignoring EAPI, or having this notion that every repository must automatically use gentoo-x86 (pushing the format into the tree) is /wrong/; aside from meaning that the format definition can now *vary*, which is great for wasting dev time and screwing up compatibility, it opens up tweaking/customizing that functionality- aka, fragmentation/divergence. If we did the sort of thing you're basically pushing for, how long do you think it would be till funtoo added support for a new archive format to unpack? That's a *simple*, and *likely* example of how this can diverge. Further, doing as you propose means we're flat out, shit out of luck /ever/ distributing a usable cache for standalone repositories. If they're bound to the changes of another repository, distributing a cache in parallel is pointless (and not doable in current form since metadata/cache lacks necessary eclass validation data for overlay inheritance). Fact is, gentoo-x86 has a lot of usable eclass in it, but it's not required to be used. Anything trying to *force* that is very short sighted and forgetting history. You want new EAPI functionality that is bash only? Awesome, eclass compatibility, and EAPI; don't just jam it into an eclass and say "EAPI is slow/annoying and I don't want to do it". Do both, everyones happy. ~harring, cranky at revisiting the same arguments over and over
Re: [gentoo-dev] x32 fun pants
On Friday, September 16, 2011 15:09:52 Thomas Sachau wrote: > Mike Frysinger schrieb: > > On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote: > >> Is a x86/amd64/x32 multilib profile just going to provide toolchain > >> support for x32 binaries (like x86 in a x86/amd64 multilib profile), or > >> do we want a 'full' x32 profile, where every package is built by default > >> as x32 code? > > > > this is an issue for the multilib-portage project > > How is this an issue for multilib-portage? the user picks which packages to build for which ABI. x32 support has nothing to do with building every package for every available ABI. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] x32 fun pants
Mike Frysinger schrieb: > On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote: >> Is a x86/amd64/x32 multilib profile just going to provide toolchain >> support for x32 binaries (like x86 in a x86/amd64 multilib profile), or >> do we want a 'full' x32 profile, where every package is built by default >> as x32 code? > > this is an issue for the multilib-portage project > -mike How is this an issue for multilib-portage? It only requires a toolchain able to build for the target and the details in environment (like possible targets and needed additional flags for each target). Thinking about the issues when starting with a new target, it might be a good idea to have the basic system (stage3) for the multilib profile to contain files for all targets, but only enable the default ABI. So when a user wants some other targets, he already has a base system, else he can just reinstall the base system and drop the unused files with this step. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x32 fun pants
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/16/11 20:32, Mike Frysinger wrote:
> On Friday, September 16, 2011 11:06:25 Markos Chandras wrote:
>> On 09/16/11 10:58, Stratos Psomadakis wrote:
>>> On 09/16/2011 10:48 AM, Michał Górny wrote:
On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger wrote:
>> PS why not merge all x86 abis into one keyword? because
>> x86_32 x86_64 x86_x32 are only abis of x86. Also we dont
>> have different keywords for different mips abis (64bit
>> and 32bit ones)
>
> that'd be nice :)
Seems even acceptable. Not sane but acceptable. People tend
to keyword packages both '~amd64 ~x86' testing them on amd64
only; amd64 users tend to get sad when someone keyworded a
package '~x86' only.
On the other hand, it'd be good to have ABI sub-keywords
then. Something like 'x86:x86 -*' if a package is actually
x86-only.
>>>
>>> I guess there are only a few cases where a package should be
>>> keyworded for eg x86, but not for amd64, so these few cases can
>>> be handled by p.masks, right?
>>>
>>> So, we can have a single x86 keyword, and a single x86
>>> 'parent' profile, and subprofiles for x86(or x86_32), amd64,
>>> and x32.
>>>
>>> I guess it's not that simple, but I think that's how the mips
>>> profiles work?
>>
>> I am a bit confused by your proposal. Do you suggest to drop
>> 'amd64' and use x86(parent)/amd64(subprofile)(for x86_64)
>> instead?
>
> that would be ideal, and drop "amd64" in the process: x86/x86_64/
> -mike
Ok so we will probably have the following multilib options
* x86(ABI=x86_32{/lib}) + amd64(ABI=x86_64{lib64/}) +
x32(ABI=x32{/libx32})
* x86/amd64 ( what we already have in amd64 multilib )
* x86/x32
and
* x86 (no multilib for 32-bit processors ) ( what we already have in
x86 profile )
Sounds doable
- --
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBCgAGBQJOc5SDAAoJEPqDWhW0r/LCHnYQAKuMpYvTWv4waSd503vfBjlb
yHPUK+Hd9itz47I3lNmxqZGl7sQxIYm6Ht6MWs3qPIrwI60biUK/vH7dK0q1dnF9
x/zSEFc6hG4nyZ94oeTtsxV7Ttsk9QK/JY2Vm1ulBbEWJeb8sfQD1lesRFV++YZn
Xeu3fMKkWoW/2m68nng7Rzfbxf2TvE7bdY3loefpXgMZf6kz7LSkNV1QidEwzs7V
yZ9C4N8G8FVFysDykqGbYKMTtn70CCKI1HZ608NY7msWm6LADwpYQYsGENX04l2O
xNpW1r+2bhSICT2TGzxIEsbspStH8g4XmRvIdXyZCbCecOyWRaAcBk9x6dY+6ZjB
mZkzauSiXGFQcVjjXdXqL1pT2NGEoGe5eWi4daH4cy/12ND76/Gt79HogBUznWTX
5A50jyEjMMHcQjDxvWOyCGvq7yxU3Njs3mNzImEmbR3j3PwlniaFs3Vz76o6yEfE
mJ0gaVP50XTDncsK9G4nrgJHKdA7BHOlWL50HXv0rsBHxkQyhsEiw5VaZUF7kOPr
R2JptEh9Kh2JyV+EfF/m74Y3Ht0jaXY0MQXV5fl5QxvavRb7WX/mzVXwjY+IlnPB
sJUcHkcNLNhm98e5j/CLn0T3DtmfqvnXSfF10wFztoUGDVOUuixVMo+ZvnGYdnH4
E4shmoxTlL7J5CzSEvpu
=wlRl
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: x32 fun pants
On Friday, September 16, 2011 01:46:49 Duncan wrote: > Mike Frysinger posted on Thu, 15 Sep 2011 17:18:43 -0400 as excerpted: > > On Thursday, September 15, 2011 17:03:07 Michał Górny wrote: > >> On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote: > >> > On Thursday, September 15, 2011 16:12:00 Michał Górny wrote: > >> > > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote: > >> > > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. > >> > > > instead, reusing "amd64". > >> > > > >> > > Hrm, wouldn't that be more like x86 keyword? AFAICS the type sizes > >> > > for x86 and x32 would match. > >> > > >> > the sizeof(long) and sizeof(void*) are the same between x86 and x32. > >> > however, that's about the only thing. for example, x32 gets access > >> > to 64bit registers when working with 64bit types (long long) and the > >> > tuple is x86_64-pc-linux- gnu. in general, it seems to be closer to > >> > amd64 than x32. > >> > >> I'm rather thinking about potential issues. But OTOH packages fixed for > >> amd64 should probably work with x32 as well. Excluding asm code which > >> would probably need a third variant then. > > > > but i'd rather not introduce another KEYWORD when we can simply p.mask > > the package, or disable the asm when ABI == x32. > > My immediate thought, probably unworkable for some reason but from here > it looks useful for at least (what would be) ~x32 and as a jump-start on > the number of ~x32 packages, and it should at least prove educational to > have it shot down ()... these things have a way of not being fixed for a very long time. p.mask in an x32 profile is a lot easier to work with and doesnt need to be "recovered" from down the line. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] x32 fun pants
On 09/16/2011 06:06 PM, Markos Chandras wrote: > On 09/16/11 10:58, Stratos Psomadakis wrote: > > On 09/16/2011 10:48 AM, Michał Górny wrote: > >> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger > >> wrote: > >> > PS why not merge all x86 abis into one keyword? because > x86_32 x86_64 x86_x32 are only abis of x86. Also we dont have > different keywords for different mips abis (64bit and 32bit > ones) > >>> that'd be nice :) > >> Seems even acceptable. Not sane but acceptable. People tend to > >> keyword packages both '~amd64 ~x86' testing them on amd64 only; > >> amd64 users tend to get sad when someone keyworded a package > >> '~x86' only. > >> > >> On the other hand, it'd be good to have ABI sub-keywords then. > >> Something like 'x86:x86 -*' if a package is actually x86-only. > >> > > I guess there are only a few cases where a package should be > > keyworded for eg x86, but not for amd64, so these few cases can be > > handled by p.masks, right? > > > So, we can have a single x86 keyword, and a single x86 'parent' > > profile, and subprofiles for x86(or x86_32), amd64, and x32. > > > I guess it's not that simple, but I think that's how the mips > > profiles work? > > I am a bit confused by your proposal. Do you suggest to drop 'amd64' > and use x86(parent)/amd64(subprofile)(for x86_64) instead? > Yeap. And if we're going to use the same keyword for x32/amd64, we can just do it for x86/amd64/x32 too. I don't think that there will be too many differences. -- Stratos Psomadakis signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: udev and /usr
Joost Roeleveld posted on Fri, 16 Sep 2011 10:36:27 +0200 as excerpted: > I agree, I just used this example to explain that it shouldn't be > necessary to force an initramfs on all users just because there is a > small group who wants to have an extreme setup. Careful with the "extreme". As you no doubt realize by now, the udev folks apparently consider anyone wanting a separate /usr but not an initr* "extreme". That'd certainly apply double if said admin (since no simple "user" cares about such stuff, in this view) had /usr on lvm. -- 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
Re: [gentoo-dev] [RFC] Adding a tiny install-mask directory list to gx86
On Fri, Sep 16, 2011 at 8:14 AM, Michał Górny wrote: > On Fri, 16 Sep 2011 08:39:48 -0500 > Donnie Berkholz wrote: > >> On 11:36 Fri 16 Sep , Michał Górny wrote: >> > The question is: where to store such a directory list? >> > >> > Keeping it inside project sources doesn't seem right as it would >> > require me to bump and re-release project every time a directory is >> > added. Keeping it in separate package which would need to be kept >> > in sync doesn't seem too good either. >> > >> > That's why I'm considering including a tiny file in gx86 (and >> > possibly other repositories) itself. Such a file could have a >> > simple format and specify mappings of 'install-mask names' (similar >> > to USE flag names) to lists of directories and possibly >> > descriptions. >> >> Do something like layman or repoman where it auto-fetches >> periodically. Layman has the advantage of also supporting add-on >> files in addition to the main one. > > I'm not sure if it's a good idea. Layman operations usually involve > network I/O, mine will not. I don't really want users to pay for GPRS > because install-mask does auto-update check. So offer a 'install-mask update' command. Drop a cronjob in cron.weekly that does the update and GRPS users can just delete / modify the job. -A > >> I don't want this in my repo. > > By *your* repo you mean dev overlay? Noone forces you to declare > additional paths. > > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] x32 fun pants
On Friday, September 16, 2011 11:06:25 Markos Chandras wrote: > On 09/16/11 10:58, Stratos Psomadakis wrote: > > On 09/16/2011 10:48 AM, Michał Górny wrote: > >> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger wrote: > PS why not merge all x86 abis into one keyword? because > x86_32 x86_64 x86_x32 are only abis of x86. Also we dont have > different keywords for different mips abis (64bit and 32bit > ones) > >>> > >>> that'd be nice :) > >> > >> Seems even acceptable. Not sane but acceptable. People tend to > >> keyword packages both '~amd64 ~x86' testing them on amd64 only; > >> amd64 users tend to get sad when someone keyworded a package > >> '~x86' only. > >> > >> On the other hand, it'd be good to have ABI sub-keywords then. > >> Something like 'x86:x86 -*' if a package is actually x86-only. > > > > I guess there are only a few cases where a package should be > > keyworded for eg x86, but not for amd64, so these few cases can be > > handled by p.masks, right? > > > > So, we can have a single x86 keyword, and a single x86 'parent' > > profile, and subprofiles for x86(or x86_32), amd64, and x32. > > > > I guess it's not that simple, but I think that's how the mips > > profiles work? > > I am a bit confused by your proposal. Do you suggest to drop 'amd64' > and use x86(parent)/amd64(subprofile)(for x86_64) instead? that would be ideal, and drop "amd64" in the process: x86/x86_64/ -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] new `usex` helper
On Fri, Sep 16, 2011 at 7:04 AM, Michał Górny wrote: > On Fri, 16 Sep 2011 07:30:14 -0500 > Donnie Berkholz wrote: > >> > Realistically I assume you're taking the stance "EAPI gets in the >> > way, lets do away with it"- if so, well, out with it, and I'll >> > dredge up the old logs/complaints that lead to EAPI. >> >> I see EAPI as a nice thing for standardizing features that are >> implemented in the PM so they work identically across portage, >> pkgcore, and paludis. But I don't think that implementing things in >> the PM when they could go in an eclass is automatically the best >> choice. It dramatically slows down the speed of iteration, >> prototyping, and bug fixing. > > What is more important is that it takes the code further from devs. > I like to see the code I use, and be able to do anything about it if > necessary. Not to see a spec and three different implementation, of > which two use random hacks which I can't do anything about unless I > start to implement PM-specific anti-hacks in my code. Just as an aside, every package mangler in Gentoo is open source. I don't see why you can't 'see' the code it is using. Now you might say 'ahhh C++ makes my eyes bleed' (as an aside, go read versionator eclass ;p) or 'eww portage is ugly' but every time I hear it I am less convinced that it is a good excuse. > > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] [RFC] Adding a tiny install-mask directory list to gx86
On Fri, 16 Sep 2011 11:42:59 -0400
Mike Frysinger wrote:
> On Friday, September 16, 2011 11:14:28 Michał Górny wrote:
> > On Fri, 16 Sep 2011 08:39:48 -0500 Donnie Berkholz wrote:
> > > I don't want this in my repo.
> >
> > By *your* repo you mean dev overlay? Noone forces you to declare
> > additional paths.
>
> i think he meant maintaining masks for pkgs in his repo for other
> pkgs (like systemd) which arent in his repo
That is not a case because install-mask will grab install-mask file
from all repos. But, well, I can keep the file in my ${FILESDIR}
as well.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] x32 fun pants
On Friday, September 16, 2011 12:01:43 Mike Frysinger wrote: > On Friday, September 16, 2011 10:06:07 Michał Górny wrote: > > But doesn't switching mean we're going to hit LFS PITA once again? > > LFS hasnt really been a pain in a long while. but it's something worth > raising on the x32 lists (which i'll do) since x32 has native 64bit support > (uint64_t == %rax). so there should be no need to have 32bit interfaces at > all for read funcs. actually, this is already done. in my libx32 libc.so.6, the 64bit ver is an alias to the 32bit ver. 5790: 000cff00 210 FUNCWEAK DEFAULT 11 openat64 6755: 000cff00 210 FUNCWEAK DEFAULT 11 openat 6055: 000d07c092 FUNCWEAK DEFAULT 11 creat 6595: 000d07c092 FUNCWEAK DEFAULT 11 creat64 so no, there shouldnt be any LFS issues with x32. all file offsets are 64bit. granted, if code does something like "int x = lseek(fd, 0, SEEK_CUR)", it'll break. but that's irrelevant to x32 ... that's broken for all 32bit systems. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] x32 fun pants
On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote: > Is a x86/amd64/x32 multilib profile just going to provide toolchain > support for x32 binaries (like x86 in a x86/amd64 multilib profile), or > do we want a 'full' x32 profile, where every package is built by default > as x32 code? this is an issue for the multilib-portage project -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] x32 fun pants
On Friday, September 16, 2011 10:06:07 Michał Górny wrote: > But doesn't switching mean we're going to hit LFS PITA once again? LFS hasnt really been a pain in a long while. but it's something worth raising on the x32 lists (which i'll do) since x32 has native 64bit support (uint64_t == %rax). so there should be no need to have 32bit interfaces at all for read funcs. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] x32 fun pants
On Friday, September 16, 2011 09:36:32 Donnie Berkholz wrote: > understanding is that it probably makes sense to switch to x32 no matter > what you're using now (x86 or amd64). x32 needs a 64bit processor, so x86 cant go away as it's the only ABI that can run on 32bit processors but for 64bit processors, it seems like x32 would be more common than x86_64. x32 comes with a 4GiB address space (since its pointers are 32bit), so there will always be a niche that wants the larger space that 64bit brings you. so long term, i wouldnt be surprised if we move to: MULTILIBS="x86 amd64 x32" DEFAULT_ABI="x32" or when multilib-portage lands, we default to just x32 (except glibc/gcc which has them all) and pull in the other two when people ask explicitly. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Adding a tiny install-mask directory list to gx86
On Friday, September 16, 2011 11:14:28 Michał Górny wrote: > On Fri, 16 Sep 2011 08:39:48 -0500 Donnie Berkholz wrote: > > I don't want this in my repo. > > By *your* repo you mean dev overlay? Noone forces you to declare > additional paths. i think he meant maintaining masks for pkgs in his repo for other pkgs (like systemd) which arent in his repo -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Adding a tiny install-mask directory list to gx86
On Fri, 16 Sep 2011 08:39:48 -0500 Donnie Berkholz wrote: > On 11:36 Fri 16 Sep , Michał Górny wrote: > > The question is: where to store such a directory list? > > > > Keeping it inside project sources doesn't seem right as it would > > require me to bump and re-release project every time a directory is > > added. Keeping it in separate package which would need to be kept > > in sync doesn't seem too good either. > > > > That's why I'm considering including a tiny file in gx86 (and > > possibly other repositories) itself. Such a file could have a > > simple format and specify mappings of 'install-mask names' (similar > > to USE flag names) to lists of directories and possibly > > descriptions. > > Do something like layman or repoman where it auto-fetches > periodically. Layman has the advantage of also supporting add-on > files in addition to the main one. I'm not sure if it's a good idea. Layman operations usually involve network I/O, mine will not. I don't really want users to pay for GPRS because install-mask does auto-update check. > I don't want this in my repo. By *your* repo you mean dev overlay? Noone forces you to declare additional paths. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] x32 fun pants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/16/11 10:58, Stratos Psomadakis wrote: > On 09/16/2011 10:48 AM, Michał Górny wrote: >> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger >> wrote: >> PS why not merge all x86 abis into one keyword? because x86_32 x86_64 x86_x32 are only abis of x86. Also we dont have different keywords for different mips abis (64bit and 32bit ones) >>> that'd be nice :) >> Seems even acceptable. Not sane but acceptable. People tend to >> keyword packages both '~amd64 ~x86' testing them on amd64 only; >> amd64 users tend to get sad when someone keyworded a package >> '~x86' only. >> >> On the other hand, it'd be good to have ABI sub-keywords then. >> Something like 'x86:x86 -*' if a package is actually x86-only. >> > I guess there are only a few cases where a package should be > keyworded for eg x86, but not for amd64, so these few cases can be > handled by p.masks, right? > > So, we can have a single x86 keyword, and a single x86 'parent' > profile, and subprofiles for x86(or x86_32), amd64, and x32. > > I guess it's not that simple, but I think that's how the mips > profiles work? > I am a bit confused by your proposal. Do you suggest to drop 'amd64' and use x86(parent)/amd64(subprofile)(for x86_64) instead? - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOc2XxAAoJEPqDWhW0r/LCUWQQAKdQ+1HcTbdNKdDkMcQna7M3 h9rWzE0BocJcXVji24hfN7JAthpvNohyIQkWgxP3HRCaOCYJ0kaXY+hC8piYrkGS HPUQ/fV2JhhSgOZpQUmZFc4Db382ILqHk44k2/vYnN27U1yC2rX/GBiZkM/jZAe3 sYZ+DR8R6FCCmquLeWX+8tqE4A11o5hzjC9cMMBVr7iGVKsonWCDgGXSLX3FMfuT gSAuRfpUHQa0ghCU/tXwH1fso/lDDhvySioJBue2ED432yknhOKtzfdye4Lg00nu M+pM36sqdF21VMvBtA1H1X5Ok927+jqS19ac8OUy8vI0qq1sIozdzKWOMICvSjf9 UDcIO1+gAA0ZGjR+n5FIrKcFgPm4uHfUFZhG50GMXm3e1TTSOel3OVEngcsYeB7p WoLPMuuZXVUrT9OXimqt5Ei2F9vkCWeh21zXSHQRmdlFvUsiPogp9ZQoL5cEAs2b wolRF+haCmRw8tpMJ1fLxba7jOATLnmS0Z0RMXzlHON0jg4/SJa8wyZnQrPiexHq rlKSI3kIzvpucvYiRn0w0ouMer835BzPpEV5xRcrX2Q2CyfP8JX/GR90ZU7iSSeh lteqVKvGzg7Nj67OKlfW1WVjPBxhB9N8lPro6PcT2sBaFyatCr+c7phtYEismubN kw2sbgrD2kp198ogymeq =biyu -END PGP SIGNATURE-
Re: [gentoo-dev] x32 fun pants
On Fri, 16 Sep 2011 08:36:32 -0500 Donnie Berkholz wrote: > On 15:34 Thu 15 Sep , Mike Frysinger wrote: > > ive converted my system over to x86/amd64/x32 multilib for funs. > > but i can see how some people wont want all three all the time. so > > the question is how we want to make this available to users at the > > release/profile level. > > > > background: x32 is a new ABI that runs on 64bit x86_64 processors. > > see [1]. you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and > > linux-3.2+. > > For anyone interested how the performance compares to amd64 in more > comprehensive tests, check out the slides from the Linux Plumbers > Conference (particularly 14-21): > > http://linuxplumbersconf.org/2011/ocw/proposals/531 > > In summary, on those benchmarks it looks like a small global win > (maybe 5%) on integer calculations with a few huge wins of ≥25%, but > a net loss around 5% pretty much globally for floating-point > calculations. > > Most people probably do a lot more integer calculations unless > they're science geeks like me, plus it should have lower memory use, > so my understanding is that it probably makes sense to switch to x32 > no matter what you're using now (x86 or amd64). > > Mike, would you agree? But doesn't switching mean we're going to hit LFS PITA once again? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Fri, 16 Sep 2011 07:30:14 -0500 Donnie Berkholz wrote: > > Realistically I assume you're taking the stance "EAPI gets in the > > way, lets do away with it"- if so, well, out with it, and I'll > > dredge up the old logs/complaints that lead to EAPI. > > I see EAPI as a nice thing for standardizing features that are > implemented in the PM so they work identically across portage, > pkgcore, and paludis. But I don't think that implementing things in > the PM when they could go in an eclass is automatically the best > choice. It dramatically slows down the speed of iteration, > prototyping, and bug fixing. What is more important is that it takes the code further from devs. I like to see the code I use, and be able to do anything about it if necessary. Not to see a spec and three different implementation, of which two use random hacks which I can't do anything about unless I start to implement PM-specific anti-hacks in my code. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: udev and /usr
On Fri, Sep 16, 2011 at 12:03 AM, Duncan <1i5t5.dun...@cox.net> wrote: > It may be that this is already sorted on the gnome side, or that all this > talk of gnome-os is simply hot-air, but like I said, I'm a kde user, so I > wouldn't know, tho I'm concerned about its implications for the rest of > us (including kde, since it might well end up with similar > requirements). And I've not yet seen it mentioned in the gentoo > implications context, so I'm compelled to ask. > > I too am a bit concerned with some of the trends here. I recently installed Ubuntu to see how it handles suspend-to-disk and compare Gentoo's support (believe it or not it worked more reliably on my Gentoo install!). However, what struck me is messages like my VM didn't meet the requirements for unity so it was falling back to classic gnome, and that got me thinking. I'm seeing a bit of a trend in the linux world towards major distros and desktop environments building these huge highly integrated platforms. Instead of having core modules that everybody shares and clear interfaces, everybody wants to build their own SysVInit replacement, their own audio system, their own window managers, their own web browsers, and so on. With Wayland on the horizon we're talking about having multiple X11 implementations/replacements possibly. Granted, KDE/Gnome have been doing this sort of thing for a while with arts/etc. However, if arts wasn't working right it didn't really keep you from getting stuff done (unless you are mixing audio for a living). I'm a bit concerned that the future of linux on the desktop is going to be one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS, or a "KDE OS." Each one would have its own package managers, repositories, distros, APIs, etc. Clearly there is some benefit from the vertical integration (Android and ChromeOS have a very high level of polish, and Ubuntu is approaching this often by just writing their own stuff). Instead of working to influence other projects (which can be frustrating), big distros are looking to just eliminate dependencies outside of themselves. This will be a big challenge for a smaller distro like Gentoo. Obviously we can't just go write our own Wayland replacement, even if we did essentially make our own "systemd" of sorts. Rich
Re: [gentoo-dev] [PATCH autotools-utils 1/9] Fix handling whitespace in filenames when looking for .la files.
On 21:53 Tue 13 Sep , Nirbheek Chauhan wrote: > On Tue, Sep 13, 2011 at 8:43 PM, Dirkjan Ochtman wrote: > > 2011/9/13 Michał Górny : > >> --- > >> eclass/autotools-utils.eclass | 2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > > > > I don't think sending 9 patches is very useful for this mailing list. > > Next time just sent a link to a git repo or something? > > > > On the contrary, I like that mgorny sent separate completely > independent patches for review to the list instead of either sending > on huge chunk, or not sending patches at all. +1, except parts of them were dependent. =) Maybe use some `git rebase --interactive` next time.. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp3Hnb8ts55I.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding a tiny install-mask directory list to gx86
On 11:36 Fri 16 Sep , Michał Górny wrote: > The question is: where to store such a directory list? > > Keeping it inside project sources doesn't seem right as it would > require me to bump and re-release project every time a directory is > added. Keeping it in separate package which would need to be kept in > sync doesn't seem too good either. > > That's why I'm considering including a tiny file in gx86 (and possibly > other repositories) itself. Such a file could have a simple format and > specify mappings of 'install-mask names' (similar to USE flag names) > to lists of directories and possibly descriptions. Do something like layman or repoman where it auto-fetches periodically. Layman has the advantage of also supporting add-on files in addition to the main one. I don't want this in my repo. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp9tWKbxQw2E.pgp Description: PGP signature
Re: [gentoo-dev] x32 fun pants
On 15:34 Thu 15 Sep , Mike Frysinger wrote: > ive converted my system over to x86/amd64/x32 multilib for funs. but i can > see how some people wont want all three all the time. so the question is how > we want to make this available to users at the release/profile level. > > background: x32 is a new ABI that runs on 64bit x86_64 processors. see [1]. > you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+. For anyone interested how the performance compares to amd64 in more comprehensive tests, check out the slides from the Linux Plumbers Conference (particularly 14-21): http://linuxplumbersconf.org/2011/ocw/proposals/531 In summary, on those benchmarks it looks like a small global win (maybe 5%) on integer calculations with a few huge wins of ≥25%, but a net loss around 5% pretty much globally for floating-point calculations. Most people probably do a lot more integer calculations unless they're science geeks like me, plus it should have lower memory use, so my understanding is that it probably makes sense to switch to x32 no matter what you're using now (x86 or amd64). Mike, would you agree? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp9K9W7gd3d2.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 02:06 Fri 16 Sep , Brian Harring wrote: > Specious argument; the point of controllable stacking was to avoid the > issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds > (which may not support those modified eclasses) via the old > PORTDIR_OVERLAY behaviour. This is why multiple repositories have > layout.conf master definitions- to explicitly mark that they > require/consume a seperate repo. So let me get this straight — instead, you want overlay users to maintain a copy of every eclass they use, which will almost automatically become outdated and stale because it won't track the gentoo-x86 version? > What you're basically proposing is a variation of the "push format > definitions into a central tree, and require everyone to use that > central tree". This discussion has come and gone; I say that being > one of the folks who was *pushing for the repository solution*. The > problem there is it fundamentally enables (more forces) fragmentation. I think Gentoo will always provide one or a set of "official" central repositories, that's pretty much the definition of a distribution. So yes, I'm saying that generally useful stuff could go into one of these repositories, which (in the multi-repo case) could be like the eclass metaphor for repos; others would depend on it implicitly or explicitly. > Realistically I assume you're taking the stance "EAPI gets in the way, > lets do away with it"- if so, well, out with it, and I'll dredge up > the old logs/complaints that lead to EAPI. I see EAPI as a nice thing for standardizing features that are implemented in the PM so they work identically across portage, pkgcore, and paludis. But I don't think that implementing things in the PM when they could go in an eclass is automatically the best choice. It dramatically slows down the speed of iteration, prototyping, and bug fixing. > rephrase please; either you're saying "everyone uses gentoo-x86" which > is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk > however which means things can get ugly for derivative repository > usage), but still ignores the situations where people have overlays w/ > developmental eclasses that they need to selectively control where it > overrides (which is where the notion of repo stacking comes into > play). I think I explained above, but let me know if that's not the case. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpQi7rzibDrE.pgp Description: PGP signature
[gentoo-dev] [RFC] Adding a tiny install-mask directory list to gx86
Hello, I'm working on a tiny project called install-mask[1] which is supposedly a simple tool to enable/disable INSTALL_MASK. One of its features would be a common list of named locations where users may really want to consider INSTALL_MASK-ing; in a way similar to USE flags (or even instead of removed USE flags). So, for example calling: install-mask -a systemd would INSTALL_MASK all locations relevant to systemd, and: install-mask -a bash-completion would mask /usr/share/bash-completion. The question is: where to store such a directory list? Keeping it inside project sources doesn't seem right as it would require me to bump and re-release project every time a directory is added. Keeping it in separate package which would need to be kept in sync doesn't seem too good either. That's why I'm considering including a tiny file in gx86 (and possibly other repositories) itself. Such a file could have a simple format and specify mappings of 'install-mask names' (similar to USE flag names) to lists of directories and possibly descriptions. This way, we could easily keep it in sync and share among our users. Moreover, overlays could easily define their own, specific INSTALL_MASK locations like they can do with USE flags right now. [1]:https://www.github.com/mgorny/install-mask/ -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] How to handle dependencies on protocol headers?
On Fri, Sep 16, 2011 at 09:08:36AM +0100, Ciaran McCreesh wrote: > On Fri, 16 Sep 2011 09:54:47 +0200 > Micha?? G??rny wrote: > > > This is a build-against dependency, and it's best expressed either > > > by its own BADEPEND, or (because it's apparently now possible, and > > > because otherwise we'd end up with six or seven *DEPEND variables) > > > by switching to something like DEPENDENCIES with a build-against > > > label. > > > > Please do not wreak exheres into Gentoo. The current variable forms > > are complex enough; there is no reason to put even more logic into > > the parser. And yes, it's better to have 7 *DEPEND variables than one > > more magical, conditional thingie in the 'Dependencies' section. > > From feedback so far, I think you're in the minority on that (at least > from people who have expressed an opinion), and that more people have > come out in favour of a single unified variable (not necessarily with > exactly the same syntax as exheres-0). Personally... I think dependencies w/ labels is fricking ugly. That said I understand the intent- being able to layer in multiple forms of deps (specifically new forms beyond what EAPI currently provides) which is good. Strikes me, this is glep territory; write it up w/ the specifics so everyone can look at it (including literal examples), and work from there. At the very least the facts would be on the table for people to read/vote on. Same instant, the folks disagreeing can pick at the failings if any, and/or write up an alternative that uses seperated vars if they think it's friendlier. Pretty much, I'd like to see this move into a realm of actual decision rather than just the current "use dependencies" "no they suck, and so do you". Alternative suggestions for moving it in that direction are welcome, but the current bickering isn't really going anywhere (this particular discussion has been appearing since eapi1 or so). Either way, we *do* need the new deps, so... getting something worked out would be preferable to having it keep dragging out. ~brian
Re: [gentoo-dev] new `usex` helper
On Thu, Sep 15, 2011 at 10:00:19PM -0500, Donnie Berkholz wrote: > On 17:29 Wed 14 Sep , Brian Harring wrote: > > On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote: > > > On 19:14 Tue 13 Sep , Brian Harring wrote: > > > > On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: > > > > > On 17:56 Tue 13 Sep , Mike Frysinger wrote: > > > > > > useful enough for EAPI ? or should i just stick it into > > > > > > eutils.eclass > > > > > > ? OR BOTH !? > > > > > > > > > > I prefer to avoid EAPI whenever possible, as it just makes things > > > > > slower > > > > > and more complex. > > > > > > > > Exactly the wrong approach; it winds up with master > > > > repositories/overlays cloning the functionality all over the damn > > > > place. > > > > > > Why are people cloning anything if it's in eutils.eclass in gentoo-x86? > > > > There are more repositories than just gentoo-x86, and overlay is *not* > > the only configuration in use. > > Who else besides you is using any other configuration? Should we really > give a crap about the 0.001% population with some weird setup when we're > trying to improve things for the 99.999% one? Specious argument; the point of controllable stacking was to avoid the issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds (which may not support those modified eclasses) via the old PORTDIR_OVERLAY behaviour. This is why multiple repositories have layout.conf master definitions- to explicitly mark that they require/consume a seperate repo. What you're basically proposing is a variation of the "push format definitions into a central tree, and require everyone to use that central tree". This discussion has come and gone; I say that being one of the folks who was *pushing for the repository solution*. The problem there is it fundamentally enables (more forces) fragmentation. Realistically I assume you're taking the stance "EAPI gets in the way, lets do away with it"- if so, well, out with it, and I'll dredge up the old logs/complaints that lead to EAPI. > > In the old days of the PM only handling a single overlay stack, what > > you're suggesting would be less heinous- heinous in detail, but > > pragmatic in reality. These days it's a regressive approach- > > requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding > > eapi (resulting in people having to duplicate code into each > > repository stack). > > I don't know many people who aren't using gentoo-x86 or a repo that > pulls in changes directly from it. rephrase please; either you're saying "everyone uses gentoo-x86" which is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk however which means things can get ugly for derivative repository usage), but still ignores the situations where people have overlays w/ developmental eclasses that they need to selectively control where it overrides (which is where the notion of repo stacking comes into play). ~brian
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 10:18:27 PM Robin H. Johnson wrote: > On Thu, Sep 15, 2011 at 11:00:47PM +0200, Joost Roeleveld wrote: > > > See below on the existing udev retry queue that is hiding many of > > > the > > > issues from you. This hidden issues are also negatively affecting > > > boot > > > times (failures and retries take time). > > > > I don't actually mind too much about the boot time. If there are retries > > like this, I would expect this to be visible in the system logs. > > udev does not log rule failures to the best of my knowledge. In other words, it silently fails... That is unfortunate. > > Either udev does this already and the execution sequence is always the > > same. In which case my suggestion above would follow the same sequence > > as the queue would be on a First-in First-out basis. > > Or, if udev doesn't do this yet, udev will end up having the same > > problem. > It doesn't do it presently. The worst case I've seen is having an early > rule that succeeds, but gives different results w/ /var mounted vs. not > mounted. This rule didn't actual fail, so it does not get retried... And here is my main concern with this. The udev team don't list all the possible filesystems where things can go wrong. They only mention /usr. > > > 1. While the binary invoked by a given rule might reside entirely on > > > a > > > > > >mounting that is already available, how do you ensure that the > > >other > > >mountpoints required by said binary are ALSO available (the > > >bluetooth and ALSA rules actually need /var, what if you have > > >a bluetooth keyboard? [see footnote]). > > > > This is why I would suggest the "actiond" process to be started after > > localmount. > > That's too late. What about all the udev rules required to get the > device nodes for localmount to succeed? Shouldn't these already exist for currently working setups? > Anyway, take your proposed split actiond/udev solution to the upstream > udev list. I don't believe that we have the manpower to develop it here. > If we did develop it here, I don't believe it will gain enough traction > amongst other distros, and we'll be stuck supporting it. > > I personally don't think your split solution covers the usage cases well > enough, but that's an actual decision best left to the upstream udev > developers. Please take the discussion there, and don't pursue it on > this list. Ok. > > > The upstream discussions I've been party to previously (both on > > > lists > > > and in person), have been trying to avoid needing a full dependency > > > system in udev, because it's a huge degree of additional complexity. > > > > I don't see why it would not be possible to pause actioning of these > > scripts till the boot-process says all required mounts are available. > > You still have to declare which scripts need to be paused, and/or which > rules inside the scripts need to be paused. Even worse are cases where > mounting some of localmount entries requires those scripts to have > completed. In other words, a dependency on the rules would be needed? > > I see this as a "solution" for the situation where someone decides to > > use > > less-common hardware and force this solution onto everyone else. > > I'm trying to get as little forced on us as possible. Gentoo is one of > the few distros at this point that doesn't already require initramfs. > While we're going to carry on supporting not requiring an initramfs as > long as possible (and documenting what is needed for that), we also > don't want this to become a stumbling block for users that just want > their system to work, and with how upstream udev and other projects are > going, there is a real possibility of breakage caused by their code, far > more than the potential of breakage because /usr failed to mount. I agree with you on this one. That is also why I am trying to get a clear picture of all the possible alternatives. > > If I would want to put my /usr filesystem on a bluetooth harddrive (for > > instance my mobile phone), then I would not expect to have this work > > without a lot of extra effort. > > While that is in the realms of extreme, having /usr or /var on NFS isn't > extreme at all. I agree, I just used this example to explain that it shouldn't be necessary to force an initramfs on all users just because there is a small group who wants to have an extreme setup. > > > udev has a retry queue already, see udev-postmount: > > > === > > > # Run the events that failed at first udev trigger > > > udevadm trigger --type=failed -v > > > === > > > > This is a retry-queue. That's a good start already, but why not redo > > this > > queue and put ALL the scripts into that queue untill after localmount? > > See above, about rules that are required for localmount to be able to > complete. The most prevalent ones would probably be devices by-uuid and > by-label. Those symlinks come from udev... These must also come from somewhere else a
Re: [gentoo-dev] x32 fun pants
On 09/15/2011 10:34 PM, Mike Frysinger wrote: > ive converted my system over to x86/amd64/x32 multilib for funs. but i can > see how some people wont want all three all the time. so the question is how > we want to make this available to users at the release/profile level. > > background: x32 is a new ABI that runs on 64bit x86_64 processors. see [1]. > you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+. > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. instead, > reusing "amd64". only downside is the existing USE=amd64 behavior, but we > can > address that by making MULTILIB_ABIS a USE_EXPAND (i think this came up > before > with the portage multilib discussion). > > release wise, we could ship a single multilib stage (x86/amd64/x32) and make > it easy to convert to a subset. that way we still need only one. > > other thoughts ? > -mike > > [1] https://sites.google.com/site/x32abi/ Is a x86/amd64/x32 multilib profile just going to provide toolchain support for x32 binaries (like x86 in a x86/amd64 multilib profile), or do we want a 'full' x32 profile, where every package is built by default as x32 code? I'm guessing that as x32 gets standarized, and providing it really outperforms amd64, most distros we'll move to using x32 binaries/libs by default. But then, what if a user wants amd64 for specific packages, which depend on shared libraries built as x32 (maybe he should just use the amd64 profile then)? -- Stratos Psomadakis
Re: [gentoo-dev] How to handle dependencies on protocol headers?
On Fri, 16 Sep 2011 09:54:47 +0200 Michał Górny wrote: > > This is a build-against dependency, and it's best expressed either > > by its own BADEPEND, or (because it's apparently now possible, and > > because otherwise we'd end up with six or seven *DEPEND variables) > > by switching to something like DEPENDENCIES with a build-against > > label. > > Please do not wreak exheres into Gentoo. The current variable forms > are complex enough; there is no reason to put even more logic into > the parser. And yes, it's better to have 7 *DEPEND variables than one > more magical, conditional thingie in the 'Dependencies' section. From feedback so far, I think you're in the minority on that (at least from people who have expressed an opinion), and that more people have come out in favour of a single unified variable (not necessarily with exactly the same syntax as exheres-0). *shrug* I don't really mind about the syntax either way, and I suspect that'll come down to a Council decision. I do care about getting the exact definitions of what the various kinds of dependencies mean right -- as you saw in the "what's available in pkg_setup?" discussion, we have to be very very careful to avoid contradictions. I think we need at least the following classes to represent all the different dependencies people seem to need: Build dependencies (DEPEND): available in src_*. Run dependencies (RDEPEND): available when the package is used to satisfy a dependency. Install dependencies (IDEPEND?): available in pkg_setup. (Anyone interested in why this is necessary should see the "Rephrasing *DEPEND" thread on gentoo-pms. Sticking something in both DEPEND and RDEPEND isn't enough, since RDEPEND-RDEPEND cycles are breakable. But please read the original discussion before claiming we're wrong.) Build-against dependencies (BDEPEND?): the thing described in the original post in this thread. Post dependencies (PDEPEND): available sometime. Suggested dependencies (SDEPEND?): optionally available sometime. We may also want: Recommended dependencies (TDEPEND?): optionally available sometime, and chosen unless the user says not to. If we're trying to solve the SCM fetch problem in EAPI 5 (I don't think we are): Special Fetch dependencies (FDEPEND?): available during the special fetch phase, however we decide to do that. Note that suggested dependencies *have* to be PDEPEND-like. You can't sensibly have suggested DEPENDs, since that violates the "repeatable builds" principle. If something's an optional DEPEND, it needs a flag. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] x32 fun pants
On Fri, 16 Sep 2011 10:58:01 +0300 Stratos Psomadakis wrote: > On 09/16/2011 10:48 AM, Michał Górny wrote: > > On Thu, 15 Sep 2011 16:35:55 -0400 > > Mike Frysinger wrote: > > > >>> PS why not merge all x86 abis into one keyword? because x86_32 > >>> x86_64 x86_x32 are only abis of x86. Also we dont have different > >>> keywords for different mips abis (64bit and 32bit ones) > >> that'd be nice :) > > Seems even acceptable. Not sane but acceptable. People tend to > > keyword packages both '~amd64 ~x86' testing them on amd64 only; > > amd64 users tend to get sad when someone keyworded a package '~x86' > > only. > > > > On the other hand, it'd be good to have ABI sub-keywords then. > > Something like 'x86:x86 -*' if a package is actually x86-only. > > > I guess there are only a few cases where a package should be keyworded > for eg x86, but not for amd64, so these few cases can be handled by > p.masks, right? Yes, that's a good idea indeed. +1 for me, and suggest pushing it to the Council. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] x32 fun pants
On 09/16/2011 10:48 AM, Michał Górny wrote: > On Thu, 15 Sep 2011 16:35:55 -0400 > Mike Frysinger wrote: > >>> PS why not merge all x86 abis into one keyword? because x86_32 >>> x86_64 x86_x32 are only abis of x86. Also we dont have different >>> keywords for different mips abis (64bit and 32bit ones) >> that'd be nice :) > Seems even acceptable. Not sane but acceptable. People tend to keyword > packages both '~amd64 ~x86' testing them on amd64 only; amd64 users > tend to get sad when someone keyworded a package '~x86' only. > > On the other hand, it'd be good to have ABI sub-keywords then. > Something like 'x86:x86 -*' if a package is actually x86-only. > I guess there are only a few cases where a package should be keyworded for eg x86, but not for amd64, so these few cases can be handled by p.masks, right? So, we can have a single x86 keyword, and a single x86 'parent' profile, and subprofiles for x86(or x86_32), amd64, and x32. I guess it's not that simple, but I think that's how the mips profiles work? -- Stratos Psomadakis
Re: [gentoo-dev] x32 fun pants
On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger wrote: > > PS why not merge all x86 abis into one keyword? because x86_32 > > x86_64 x86_x32 are only abis of x86. Also we dont have different > > keywords for different mips abis (64bit and 32bit ones) > > that'd be nice :) Seems even acceptable. Not sane but acceptable. People tend to keyword packages both '~amd64 ~x86' testing them on amd64 only; amd64 users tend to get sad when someone keyworded a package '~x86' only. On the other hand, it'd be good to have ABI sub-keywords then. Something like 'x86:x86 -*' if a package is actually x86-only. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] How to handle dependencies on protocol headers?
On Fri, 16 Sep 2011 07:25:29 +0100 Ciaran McCreesh wrote: > On Fri, 16 Sep 2011 00:32:49 -0400 > Matt Turner wrote: > > Often packages depending on X11 libraries will also have to specify > > the X11 libraries' proto packages in DEPEND. This is because the X11 > > library itself #includes files provided by the proto package. It's > > not really that the X11 library depends on this at run-time, so the > > protocol packages aren't specified in the RDEPEND of the libraries. > > This is a build-against dependency, and it's best expressed either by > its own BADEPEND, or (because it's apparently now possible, and > because otherwise we'd end up with six or seven *DEPEND variables) by > switching to something like DEPENDENCIES with a build-against label. Please do not wreak exheres into Gentoo. The current variable forms are complex enough; there is no reason to put even more logic into the parser. And yes, it's better to have 7 *DEPEND variables than one more magical, conditional thingie in the 'Dependencies' section. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Fri, Sep 16, 2011 at 09:25:12AM +0200, Joost Roeleveld wrote: > > I've found that dracut is pretty auto-magic by default and the config file > > doesn't generally need tampering. Most of the options are to NOT load > > modules or to minimize the initramfs size by figuring out what modules are > > actually needed and only load those (which means if you change hardware > > between boots it could come up short). > If I change hardware, the kernel is likely not to boot as I disable anything > I > don't have. If that's the case, when you change your kernel ahead of changing hardware, change dracut too. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 08:32:17 PM Rich Freeman wrote: > On Thu, Sep 15, 2011 at 5:48 PM, Joost Roeleveld wrote: > > Will the ebuild automatically add all the different modules into the > > /etc/dracut.conf ? > > Please note, I am asking these questions to put my mind at ease and > > hopefully > > be able to explain all this back to the people on gentoo-user. > > Honestly, I'd recommend just trying it out. Dracut right now is as usable > as any non-initramfs solution out there and you can always add it as an > extra non-default option in grub so that it doesn't mess you up if it > doesn't work. It is on my list of things to test and I will let you know my findings. > I've found that dracut is pretty auto-magic by default and the config file > doesn't generally need tampering. Most of the options are to NOT load > modules or to minimize the initramfs size by figuring out what modules are > actually needed and only load those (which means if you change hardware > between boots it could come up short). If I change hardware, the kernel is likely not to boot as I disable anything I don't have. > The modules that are available are controlled by use flags. Actually, I > think it is a DRACUT_MODULES variable or something like that (not unlike how > X11 handles drivers). Yes, this matches what I have found out already. -- Joost
