[gentoo-dev] Re: Re: [gentoo-dev] About DELL ALPS touchpad
definitely was set to y CONFIG_MOUSE_PS2_ALPS=y The touchpad was, but just basicly. So I want to full featured such as multi-touch and scroll 2014-07-04 Thanks & Best Regards. 陶治江 | TAO Zhijiang 研发处 | SOHO国际产品线 发件人： Chí-Thanh Christopher Nguyễn 发送时间： 2014-07-03 17:19:31 收件人： gentoo-dev; gentoo-user 抄送： 主题： Re: [gentoo-dev] About DELL ALPS touchpad taozhijiang schrieb: > Hello, everyone > > I am using DELL Latitiude Laptop, comes with ALPS touchpad. > > When I installed the driver in Windows, this touchpad supports > multi-touch very well. > I am now using the latest Gentoo with KDE descktop environment, and I > also want to > enjoy the multi-touch functions, but this is not supported. Check your kernel configuration that CONFIG_MOUSE_PS2_ALPS is enabled. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] new profile layout with flavors and mix-ins
On Thu, Jul 3, 2014 at 7:09 PM, Tom Wijsman wrote: > Did the Funtoo devs tell you that they don't run repoman because of the > explosive set of possible combinations that flavors & mix-ins introduce? > > Having it run over them should be easy; but having it run within a > reasonable time when scaling up is going to be quite painful, ... I don't think we need to check all the combinations. To keep things manageable I think we'd want to define some structure around the profiles and what different kinds of profiles should and shouldn't do. If a profile just pulls in some packages and sets some application-oriented USE flags we shouldn't really need to worry about conflicts - if there are any users will either learn not to run them in combination or at least they won't end up with a completely cripped system if some non-core applications have issues.Messing with ABIs or system-wide configuration settings should be reserved for specific types of profiles which wouldn't be run in combinations unless carefully controlled. We should definitely avoid the mess of inheritance that leads to settings being toggled back and forth. Even if we still end up being stuck with a kernel/arch/subarch hierarchy we'll at least be able to ditch layering on things like kde/gnome further down and open the door to having more variety in our profiles at that level. Something like x32 coming along is fairly rare, even if it is really interesting (and this stuff is one of Gentoo's strong points, actually). There is probably a lot more interest in having more application-level mix-ins in the main tree, or especially in overlays. The reason we avoid them is that today they'd lead to 300 more profiles on top of what is already a big mess. If that part of the tree gets flattened there is no reason somebody could have a minimal profile that doesn't stick openssh in @system, or a bunch of server profiles for various use cases, or some profiles for clusters, config-managed boxes, etc. So, if we come up with a decent strategy, deciding what repoman does and doesn't have to worry about would be part of it. We obviously can't check all the combos, but that doesn't mean that we can't make sure that linux/x86/foo doesn't break. Rich
Re: [gentoo-dev] new profile layout with flavors and mix-ins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 02 Jul 2014 14:41:03 -0400 "Rick \"Zero_Chaos\" Farina" wrote: > I've talked to the funtoo devs a few times about stealing their > profile idea. A few things need to be done to make this happen, > mainly eselect, catalyst, and repoman support. I can do the eselect > and catalyst changes myself, however, I'll require some help for the > repoman support most likely. I'll prototype this locally, see what I > can make work, and then see about making it usable for others to test. Did the Funtoo devs tell you that they don't run repoman because of the explosive set of possible combinations that flavors & mix-ins introduce? Having it run over them should be easy; but having it run within a reasonable time when scaling up is going to be quite painful, ... It sounds like a trade-off between better profiles and better repoman. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTteLDAAoJEPWZc8roOL/QXbIIAJpM1QZhfu51deklcxIi+6PJ 6yxNc1CA6eJfhQouGYR2QgEHUI4YASEz0invFpXbv4IM/NYY/JSX/e+EOoykqcub eN9ZIFcUOdnuP7GnG+tVOe0oMJ0jhj7yEB/+Iifz63qPlL04gMqZDYnMpz2EIrUB 2SmiFKaxWaJBv/nFoVF2ErWuNjVTMwZE8cP7Eob2HO+G2N2tLbRVMf0cJPOYHGGt 00Y+4c8EPnWvdcnHN0ei14FyTYKb+eRnvGsN5xqTnMw6oG/bGhEiHtIkdMGfrzfq UeG5cPGfxll7u8m9isA22c+lKdtnLZ9EIQtPs7Jxg09hSW3HqiNgkA5b/o/m+1A= =ROh0 -END PGP SIGNATURE-
Re: [gentoo-dev] should /etc/init.d/sysctl be run in lxc guests?
03.07.2014 20:02, William Hubbs пишет: > This is a question to lxc users, since I don't run it. > > I have a bug against OpenRC in which the user is saying that I should > allow /etc/init.d/sysctl to run inside an lxc container [1]. > > My understanding is that this is not a good idea since an lxc container > actually changes settings in the host's kernel. > > The user's position seems to be that it should be up to the lxc > template or the sys admin to make sure they configure things correctly. > > Does anyone have any thoughts? Is this something I should allow people > to shoot themselves in the foot with if they do something wrong? > > Thanks, > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=516050 > Comment #3 in bug mostly right. By dropping CAP_SYS_ADMIN you can prevent of changing most of the global sysctl settings. Other settings still can be changed by root inside the container, but these settings are separate and unique to each container(like ip_forward and all the network stuff that sits in network namespace). -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new profile layout with flavors and mix-ins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/07/14 04:47 AM, Joshua Kinard wrote: > On 07/03/2014 03:00, Michael Haubenwallner wrote: >> >> On 07/03/2014 08:18 AM, Joshua Kinard wrote: >>> On 07/02/2014 13:54, Michał Górny wrote: Dnia 2014-07-02, o godz. 10:44:16 >>> [snip] I don't feel like we ought to vote on something like this without understanding most of the current profiles. And I'm afraid there are only few people who have any idea about the current profile structure... >>> >>> I am going to throw this out there and see what people think. >>> Maybe it's insane, maybe it's not, maybe it's a mix of insane >>> and not-insane. >>> >>> Years ago, before we had the current stacking profile design >>> (we were discussing the current design, actually), I kinda >>> conjured up this "building blocks" like approach for a profile >>> design. >> >>> The idea being that, in /etc/make.conf (or wherever that file >>> is now), you'd define $PROFILE like this: >>> >>> linux-mips o32 uclibc server: >>> PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0" >> >> >>> What about making /etc/portage/make.profile a directory rather than a symlink, >> having /etc/portage/make.profile/parent to reference all the >> flavours? >> >> Tools that need to respect the /current/ profile should work >> without any change, and tools that need to respect the >> /available/ profiles (repoman) already do have a list of profiles >> to respect (profiles/profiles.desc). >> >> So the only missing thing would be the eselect profile module to >> manage entries of /etc/portage/make.profile/parent, maybe using >> /usr/portage/profiles/profiles.desc as the source for available >> flavours. >> >> my 2 cents /haubi/ > > That's the thing, make.profile technically *is* a directory -- a > symlink to one. The original design of make.profile was to specify > generic, base settings for a given profile and keep that in the > tree. Things like default CHOST, default ARCH, default , > etc. make.conf then overrides in-tree settings with settings > specific to your system. So making /etc/make.profile an actual > directory disconnects it from the tree, which I don't think will > work very well for Portage, since it won't know what your > currently-chosen profile is. > I did a test where I dropped my make.profile symlink, made a directory of the same name, and populated a 'parent' file in that directory with paths to various /usr/portage/profiles/ bits which made up my previous main profile. Everything continued to work as expected. I expect for portage proper, we could accomodate mixins or whatever new structure method we want simply by adjusting 'eselect profile' to list the various possible combinations and adjust an /etc/make.profile/parent file accordingly. (We probably also need to ensure portage warns or errors appropriately when one of these inherit lines in the parent file no longer points to a directory, the same as it does now with the symlink points to nothing; I didn't test but I expect that error would not be pretty or easily understood right now) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlO1f4IACgkQ2ugaI38ACPB1wgEApznnssegz2ImYIq6fAeR2oGa RX0TNT6bThDcypkn0skA/j/w33cWekomOQanCKIspuOWxXgOAeMxMWlnhsORZfj7 =Qwj0 -END PGP SIGNATURE-
[gentoo-dev] should /etc/init.d/sysctl be run in lxc guests?
This is a question to lxc users, since I don't run it. I have a bug against OpenRC in which the user is saying that I should allow /etc/init.d/sysctl to run inside an lxc container [1]. My understanding is that this is not a good idea since an lxc container actually changes settings in the host's kernel. The user's position seems to be that it should be up to the lxc template or the sys admin to make sure they configure things correctly. Does anyone have any thoughts? Is this something I should allow people to shoot themselves in the foot with if they do something wrong? Thanks, William [1] https://bugs.gentoo.org/show_bug.cgi?id=516050 signature.asc Description: Digital signature
Re: Re: [gentoo-dev] new profile layout with flavors and mix-ins
Am Mittwoch 02 Juli 2014, 15:07:12 schrieb Anthony G. Basile:
>
> I don't know how to get from here to there. The problem isn't just
> constructing an alternative profile tree. We could even have
> /usr/portage/profiles-r2 and switch between the two on demand. The
> problem is there's a lot of memory with flags and masks and these only
> make sense in the context of the current stacking profiles.
> Disentangling this information and bringing it over to profiles-r2 is
> going to be work.
Crazy idea:
* introduce a change that makes portage look at a new filename for
inheritance, i.e. existing "parent" files are disregarded and a new filename
is introduced ("inherits" ?)
* in most dirs that file will not exist -> no inheritance
* new profile specs will have new main directories that pull in the resulting
flat structure piece by piece
This means that existing files can (carefully) be re-used in the transition.
--
Andreas K. Huettel
Gentoo Linux developer
kde, council
Re: [gentoo-dev] Making a common sub-profile for no-multilib
Michał Górny wrote: > > abi/x86 can't be both a file and a subdir. > > Profiles are directories... Doh, yes of course. :\ abi rather than abis is still important. :) //Peter pgp7Suon0xtIh.pgp Description: PGP signature
Re: [gentoo-dev] Making a common sub-profile for no-multilib
On Thu, Jul 3, 2014 at 8:07 AM, Peter Stuge wrote: > This can't work; abi/x86 can't be both a file and a subdir. Profiles ARE subdirs. Most of our existing profiles are stacked in this way. This would become less-so if we went with the mix-in approach, but it wouldn't be entirely flat in this proposal. Rich
Re: [gentoo-dev] Making a common sub-profile for no-multilib
Dnia 2014-07-03, o godz. 14:07:28 Peter Stuge napisał(a): > Michał Górny wrote: > > The arch/ tree starts with 'generic' subdirectories matching main > > arches -- like arm, mips, x86, sparc, powerpc, s390 (but not amd64). > > I like this idea, but.. > > > > Each of arch trees contains an 'abis' subtree that contains mix-ins > > ..please please call this 'abi' instead. > > > > For example, the expanded inherits for arch/x86/multilib/amd64 would > > go like: > > > > 1. arch/base -- that disables a lot of uncommon stuff, > > 2. arch/x86/base [optionally] -- setting some generic defaults, > > Fine so far. > > > 3. arch/x86/abis/x86 -- setting support for 'x86' ABI, > > 4. arch/x86/abis/x86/lib32 [optionally] -- overriding LIBDIR_x86 for > > compatibility with current SYMLINK_LIB screwup, > > This can't work; abi/x86 can't be both a file and a subdir. > Maybe call them abi/x86 and abi/x86_SYMLINK_LIB_compatibility ? > (Or x86_lib32, although that is a lot less descriptive.) Profiles are directories... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Making a common sub-profile for no-multilib
Michał Górny wrote: > The arch/ tree starts with 'generic' subdirectories matching main > arches -- like arm, mips, x86, sparc, powerpc, s390 (but not amd64). I like this idea, but.. > Each of arch trees contains an 'abis' subtree that contains mix-ins ..please please call this 'abi' instead. > For example, the expanded inherits for arch/x86/multilib/amd64 would > go like: > > 1. arch/base -- that disables a lot of uncommon stuff, > 2. arch/x86/base [optionally] -- setting some generic defaults, Fine so far. > 3. arch/x86/abis/x86 -- setting support for 'x86' ABI, > 4. arch/x86/abis/x86/lib32 [optionally] -- overriding LIBDIR_x86 for > compatibility with current SYMLINK_LIB screwup, This can't work; abi/x86 can't be both a file and a subdir. Maybe call them abi/x86 and abi/x86_SYMLINK_LIB_compatibility ? (Or x86_lib32, although that is a lot less descriptive.) > 5. arch/x86/abis/amd64 -- setting support for 'amd64' ABI, > 6. arch/x86/abis/amd64/default [optionally] -- setting 'amd64' > as default ABI, Same here with abi/amd64 being both file and subdir. > 7. arch/x86/multilib/amd64 -- finishing multilib setup. I think it looks good. //Peter pgpW5IK6eGEDK.pgp Description: PGP signature
Re: [gentoo-dev] Making a common sub-profile for no-multilib
Dnia 2014-06-25, o godz. 13:01:48 Ian Stakenvicius napisał(a): > I would like to propose adding 'no-multilib/[arch]/package.mask' > sub-profile(s), to allow all of these masks to go in one place. > > Populating package.mask should be fairly easy for amd64 at least, > since anything depending on an app-emulation/emul-* will need to be > masked. However the merits of where the package.mask will go needs > discussion. Perhaps, for instance, it's time to adjust the profile > tree hierarchy more aggressively instead of "piling on" with yet > another subdir. > > Thoughts? I would go for a bit different way of handling arch profiles. This is an early idea that probably can't work but could make things a little bit easier to mangle. The arch/ tree starts with 'generic' subdirectories matching main arches -- like arm, mips, x86, sparc, powerpc, s390 (but not amd64). Each of arch trees contains an 'abis' subtree that contains mix-ins describing particular ABIs supported. For example, arch/x86/abis/x86, arch/x86/abis/amd64, arch/mips/abis/o32. Each of those mix-ins describes that basic stuff for ABI (like LIBDIR, standard CHOST), unmasks relevant ABI flags and p.masks them on packages that don't support a particular ABI. Now, each of those mix-ins may come with a sub-profile called 'default' that sets use.force & make.defaults for making the ABI the default ABI. I'm currently not sure if this will be really helpful since the small amount of work we may also put directly into 'real' profiles (described below). Moreover, each of those mix-ins may come with a 'no-multilib' sub-profile. This one -- aside from setting all the standard variables -- package.masks all the packages that were package.use.mask in parent profile. This way, we can keep all the masks almost in a single place. Then, we have multilib profiles like arch/x86/multilib/amd64, arch/x86/multilib/x32. Those inherit from all the relevant ABI profiles -- e.g. amd64 would inherit arch/x86/abis/x86 & arch/x86/abis/amd64[/default], and set the remaining variables for multilib. While I feel it's a bit complex, I think that's somehow a sane way to express what we have now without moving back and forth. Few extra key points: - minimal no of profiles in each 'parent' -- supposedly abis/ would have no parents, and possibly final profiles would have 'arch/base' as parent, - as already mentioned somewhere else, i'd rather see 'arch/base' instead of plain 'base' -- the idea is to put everything that's easier reverted than copied through all arch/ profiles, and have it inherited only by the final arch profiles. For example, the expanded inherits for arch/x86/multilib/amd64 would go like: 1. arch/base -- that disables a lot of uncommon stuff, 2. arch/x86/base [optionally] -- setting some generic defaults, 3. arch/x86/abis/x86 -- setting support for 'x86' ABI, 4. arch/x86/abis/x86/lib32 [optionally] -- overriding LIBDIR_x86 for compatibility with current SYMLINK_LIB screwup, 5. arch/x86/abis/amd64 -- setting support for 'amd64' ABI, 6. arch/x86/abis/amd64/default [optionally] -- setting 'amd64' as default ABI, 7. arch/x86/multilib/amd64 -- finishing multilib setup. The key point here being that no profile is run twice. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making a common sub-profile for no-multilib
Dnia 2014-07-03, o godz. 09:05:47 Duncan <1i5t5.dun...@cox.net> napisał(a): > Jonathan Callen posted on Thu, 03 Jul 2014 03:05:46 -0400 as excerpted: > > > I did, however test when a package installs two (different) regular > > files into paths that end up symlinked, and found that portage does > > break in that case (as the only sensible option at that point is to > > fail, as something will be lost in either case). > > Indeed, and good point. > > I guess at that point it's basically a pkg-collision, except that it's in > a single package instead of two different packages. Too bad a package > can't block itself and thus handle it the way different packages blocking > each other handle that case! =;^) > > That's why symlinking both lib64 and lib32 to lib isn't a particularly > good idea! =;^) Symlinking anything to lib wasn't ever a particularly good idea. We will spend a lot of effort fixing that (see the SYMLINK_LIB=no bug [1]). [1]:https://bugs.gentoo.org/show_bug.cgi?id=506276 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About DELL ALPS touchpad
taozhijiang schrieb: > Hello, everyone > > I am using DELL Latitiude Laptop, comes with ALPS touchpad. > > When I installed the driver in Windows, this touchpad supports > multi-touch very well. > I am now using the latest Gentoo with KDE descktop environment, and I > also want to > enjoy the multi-touch functions, but this is not supported. Check your kernel configuration that CONFIG_MOUSE_PS2_ALPS is enabled. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: Making a common sub-profile for no-multilib
Jonathan Callen posted on Thu, 03 Jul 2014 03:05:46 -0400 as excerpted: > I did, however test when a package installs two (different) regular > files into paths that end up symlinked, and found that portage does > break in that case (as the only sensible option at that point is to > fail, as something will be lost in either case). Indeed, and good point. I guess at that point it's basically a pkg-collision, except that it's in a single package instead of two different packages. Too bad a package can't block itself and thus handle it the way different packages blocking each other handle that case! =;^) That's why symlinking both lib64 and lib32 to lib isn't a particularly 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
[gentoo-dev] Re: new profile layout with flavors and mix-ins
Michael Haubenwallner wrote:
>
>> The idea being that, in /etc/make.conf (or wherever
>> that file is now), you'd define $PROFILE like this:
>>
>> linux-mips o32 uclibc server:
>> PROFILE="base:kernel/linux:arch/mips:[...]"
>
> What about making /etc/portage/make.profile a directory
> rather than a symlink, having /etc/portage/make.profile/parent
> to reference all the flavours?
/etc/portage/make.profile already *is* a directory
(only on most user systems it is currently implemented as a symlink
to a directory from the portage tree, but there is no technical
requirement to do that).
I can assure you (from some requests I got as a maintainer of eix
to implement this correctly) that already quite some people
use such an approach:
They specify in the "parent" file (either in their
/etc/portage/make.profile or in /etc/portage/profiles/...)
all sort of additions to profiles which they have written themselves
for various tasks.
So, technically, all this is already covered by portage and
existing tools; no new magic "PROFILE" variable or similar things
have to implemented, and no tools (like eix) need to be changed.
It might, however, be appropriate to reorganize the profile structure
to support this approach better.
> So the only missing thing would be the eselect profile module
> to manage entries
Yes, if you want a user interface for convenient handling of
such a new profiles style, this would need to be written.
However, such a user interface ("eselect profile"?) is perhaps
overkill: The user should be able to handle a single configuration
file "parent" if it is described in the documentation.
The documentation would need to be updated, of course:
Currently, users have to read pms or similar things to understand
what the "parent" file is for...
Also a news item would be appropriate for such a major change, of course.
[gentoo-dev] Re: new profile layout with flavors and mix-ins
Michael Haubenwallner posted on Thu, 03 Jul 2014 09:00:18 +0200 as excerpted: > What about making /etc/portage/make.profile a directory rather than a > symlink, having /etc/portage/make.profile/parent to reference all the > flavours? We /almost/ have that already. I've long thought that /etc/portage/ profile should be the "real" profile instead of an override of the real profile, in which case it would have a parent file as you suggested, which could have multiple listed parents. Then /etc/portage/make.profile could be done away with, or more likely at least for a time, for compatibility reasons simply be a symlink -> profile. Then users would simply directly modify their /etc/portage/profile profile, including its parent file, as desired, instead of having the /etc/portage/make.profile symlink, with /etc/portage/profile being yet another layer on top of that. For all I know that might actually work right now as I've not tried it, but the portage (5) manpage does specifically say /etc/portage/profile supports all profile files EXCEPT parent, so unless the documentation is wrong... Assuming the documentation is correct, however, "all" we'd need to do on the user side would be to make portage and the other tools treat the parent file in /etc/portage/profile just as they do in other profile dirs, create an eselect module or equivalent to help manage that parent file, and update the documentation including the handbook accordingly. Updating other tree related tools would be required as well, of course, but as already pointed out, the real work would probably be in designing and setting up the new "flatter" profile tree layout and finding the appropriate new-layout location for all the existing settings. -- 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] new profile layout with flavors and mix-ins
On 07/03/2014 03:00, Michael Haubenwallner wrote: > > On 07/03/2014 08:18 AM, Joshua Kinard wrote: >> On 07/02/2014 13:54, Michał Górny wrote: >>> Dnia 2014-07-02, o godz. 10:44:16 >> [snip] >>> >>> I don't feel like we ought to vote on something like this without >>> understanding most of the current profiles. And I'm afraid there are >>> only few people who have any idea about the current profile >>> structure... >>> >> >> I am going to throw this out there and see what people think. Maybe it's >> insane, maybe it's not, maybe it's a mix of insane and not-insane. >> >> Years ago, before we had the current stacking profile design (we were >> discussing the current design, actually), I kinda conjured up this "building >> blocks" like approach for a profile design. > >> The idea being that, in /etc/make.conf (or wherever that file is now), you'd >> define $PROFILE like this: >> >> linux-mips o32 uclibc server: >> PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0" > > What about making /etc/portage/make.profile a directory rather than a symlink, > having /etc/portage/make.profile/parent to reference all the flavours? > > Tools that need to respect the /current/ profile should work without any > change, and > tools that need to respect the /available/ profiles (repoman) already do have > a list > of profiles to respect (profiles/profiles.desc). > > So the only missing thing would be the eselect profile module to manage > entries of > /etc/portage/make.profile/parent, maybe using > /usr/portage/profiles/profiles.desc > as the source for available flavours. > > my 2 cents > /haubi/ That's the thing, make.profile technically *is* a directory -- a symlink to one. The original design of make.profile was to specify generic, base settings for a given profile and keep that in the tree. Things like default CHOST, default ARCH, default , etc. make.conf then overrides in-tree settings with settings specific to your system. So making /etc/make.profile an actual directory disconnects it from the tree, which I don't think will work very well for Portage, since it won't know what your currently-chosen profile is. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] new profile layout with flavors and mix-ins
On 07/03/2014 03:32, Michał Górny wrote: > Dnia 2014-07-03, o godz. 02:18:23 > Joshua Kinard napisał(a): > >> [...] >> >> And so on. The goal was to have profiles/ be extremely flat, with limited >> nesting only for categorization purposes. Each component would contain all >> of the information specific to that component, and rely on OOP-like >> inheritance to override parent-level variables only within that component >> (although, and would have to be a little bit more broad in >> scope). > > Another sub-thread, the same question: how do you handle information > that needs to be applied to the intersection of the profiles? CHOST for > amd64 FreeBSD, for example. Well, as I stated, I thought the bulk of this up *years* ago (at least 6-7 years ago, probably longer). The issues you're raising now weren't issues back then. I only updated it slightly based on what I know now about how we do things and what things are supported in Gentoo. I am only proposing it as a base from which others to think about and either build upon or enhance, or strike it down. >> PROFILE also had a set order for the first few pieces, if only to make >> parsing and building the profile stack saner for the Portage developers: >>PROFILE="base::[:]::" >> >> base - Core Gentoo/Portage/whatever information/vars/foobar/kittens > > I'm against plain 'base' since it quickly becomes a mess. I would > prefer having flavor-specific bases, like for example arch/base to mask > stuff available only in 1/2 arches and revert it in another arch/. The only reason I put a 'base' folder in was so that where was some kind of anchor point for Portage to build off of. I didn't put any thought into what it might actually contain. For all intents and purposes, it might just contain empty variable declarations, kinda like an abstract base class in an OOP language. By itself, it's unusable and must be overridden, but it's the point from which everything derives. Maybe that's not needed now in current Portage. Dunno. >> kernel - Specifies the OS kernel. At the time, only Linux existed, but >> I *think* Debian was eyeballing kFreeBSD at the time. So I *think* >> I accounted for it back then. > > What about kernel-ABI intersection? What about Prefix? I know very little about Prefix. Any new profile system we create should focus only what is in-tree *first*, then once we work the bugs and kinks out, we can figure out how Prefixes will be incorporated. But that said, what little I do know about Prefix is that it's Portage ported to other OSes, like Solaris, MacOS, Interix, IRIX, etc. I guess an out-of-tree Prefix overlay would just define missing bits in its profiles/* folder. I.e., for Solaris, you'd have a kernel/solaris, libc/solaris-libc, etc. I'm not the best at OOP-designs, but if we set the in-tree stuff up right, it should be trivial for out-of-tree overlays to extend and override to support things, without going down the endlessly-nested directory snafu that the current profile system is. In-tree should be as flat as possible, Prefix and other external overlays can extend it out however far they want. As for kernel-ABI intersection, can you expand on that a little more? A given kernel can support multiple ABIs simultaneously. Using MIPS as the classic example, a 32-bit MIPS kernel only does o32, but a 64-bit kernel does n64 natively, and you can enable o32 and n32 support individually within the configuration. And MIPS has even more obscure ABIs that aren't well-known, either. >> arch - Machine arch-specific generic information -- doesn't handle >>lower-level things like ISAs/ABIs/Endian, etc. >> >> subarch - Defines items specific given to given subarch of a main arch. >> Items under this directory would carry their parent arch's >> name for clarity only. Again, at the time, MIPS would have been >> the only real user of this, and, back then, it would've dealt >> with SGI-machine-specific packages and USE flags, such as >> differentiating an ip32 machine from an ip27 machine or a >> cobalt. Now that amd64/x86_64 is considering its own form of >> n32 (x32), that would go here, and I imagine arm would >> make heavy use of it as well. > > This is a no-go for multilib support. We need to work on a consistent > arch profile tree, not more splitting. Well, it'll have to be nested somehow. A given arch can handle multiple ABIs, so there should at least be a top-level arch/ folder that defines very high-level, very generic things specific to a given arch. How we fold the multilib and multiple ABI stuff in probably needs a lot of thought. It may not be possible with this proposed idea, so, if not, we'll need to think of something else. Also keep in mind that with MIPS, we up the fun fun with the ISA (Instruction Set Architecture) mess (mips1 to mips4, mips32r2, mips64r2, etc), which are also mostly independent o
Re: [gentoo-dev] new profile layout with flavors and mix-ins
Dnia 2014-07-03, o godz. 02:18:23 Joshua Kinard napisał(a): > [...] > > And so on. The goal was to have profiles/ be extremely flat, with limited > nesting only for categorization purposes. Each component would contain all > of the information specific to that component, and rely on OOP-like > inheritance to override parent-level variables only within that component > (although, and would have to be a little bit more broad in > scope). Another sub-thread, the same question: how do you handle information that needs to be applied to the intersection of the profiles? CHOST for amd64 FreeBSD, for example. > PROFILE also had a set order for the first few pieces, if only to make > parsing and building the profile stack saner for the Portage developers: >PROFILE="base::[:]::" > > base - Core Gentoo/Portage/whatever information/vars/foobar/kittens I'm against plain 'base' since it quickly becomes a mess. I would prefer having flavor-specific bases, like for example arch/base to mask stuff available only in 1/2 arches and revert it in another arch/. > kernel - Specifies the OS kernel. At the time, only Linux existed, but > I *think* Debian was eyeballing kFreeBSD at the time. So I *think* > I accounted for it back then. What about kernel-ABI intersection? What about Prefix? > arch - Machine arch-specific generic information -- doesn't handle >lower-level things like ISAs/ABIs/Endian, etc. > > subarch - Defines items specific given to given subarch of a main arch. > Items under this directory would carry their parent arch's > name for clarity only. Again, at the time, MIPS would have been > the only real user of this, and, back then, it would've dealt > with SGI-machine-specific packages and USE flags, such as > differentiating an ip32 machine from an ip27 machine or a > cobalt. Now that amd64/x86_64 is considering its own form of > n32 (x32), that would go here, and I imagine arm would > make heavy use of it as well. This is a no-go for multilib support. We need to work on a consistent arch profile tree, not more splitting. > libc - Defines the main C library used. A bit redundant for *BSD, because >they really only have one, but might help if we ever add k*BSD >support (such as freebsd/glibc-based or such). For Linux...could be >tricky, since there are so many libc possibilities there. I feel it >fits better getting defined after , especially in the case >of MIPS. I think you need to handle kernel & libc in the same group. > eapi - EAPI didn't exist back when this topic was visited. Basically, >everything was EAPI=0 and there was only Portage (Paludis nor >pkgcore had been invented yet). And what is this supposed to do? > releases - I don't think this existed back then. How it'd operate >nowadays, I have no idea. Probably would contain >version-specific maskings for specific @system packages >to facilitate upgrading, and help us if we ever tried to cut >actual, fixed release points again (like what FreeBSD does >w/ -RELEASE-x.y) I don't think releases would make any sense without heavy intersection with other profiles. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Making a common sub-profile for no-multilib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/03/2014 12:59 AM, Duncan wrote: > Jonathan Callen posted on Wed, 02 Jul 2014 19:06:59 -0400 as > excerpted: > >> On 07/02/2014 02:14 PM, Duncan wrote: >>> Rich Freeman posted on Wed, 02 Jul 2014 09:30:50 -0400 as >>> excerpted: >>> Some things to think about include multilib (just another arch?), systemd, and usr-merge. >>> >>> FWIW, systemd with merge to / (/usr being a symlink to . and >>> sbin to bin) here. In particular, the merge "just works" with >>> current portage. I'm no-multilib. >>> >> That merge only works because you happened to get lucky, and >> have portage merge coreutils in a particular manner >> (/usr/bin/uname installed before /bin/uname). If portage had >> installed /bin/uname first, you would have ended up with a >> /bin/uname symlink pointing to /bin/uname. The same is also true >> of basename, chroot, cut, dir, dirname, du, env, expr, head, >> mkfifo, mktemp, readlink, seq, sleep, sort, tail, touch, tr, tty, >> vdir, wc, and yes. > > No, it works because, as I specifically asked the portage folks > about before I tried it, portage has had symlink merge intelligence > for some time now. Apparently well before I asked (in May, 2013, > according to my portage-devel list archives), some portage dev > considered the possibility of directory symlinks triggering > overwrites of targets with the symlinks pointing to them, and > ensured that portage's qmerge code "just did the right thing." > > I did nothing with the answer for some time, but eventually decided > to try it. As I was a bit skeptical/careful at first, after doing > the initial manual moves and thus finding which files existed in > both target dirs, then deleting the individual file symlinks, > moving the remaining files to the new location and making the old > directory a symlink, I equery-belonged the symlinks and manually > remerged (from binpkg, which still stores the symlinks in their > usual location in the binpkg tarball) several of the packages one > at a time, first a non-critical one, then I think coreutils itself, > just to be sure, then 2-3 others together, and sure enough, it > "just worked" the way it was supposed to work. > > =:^) > >> I myself am currently running a system with the opposite merge >> (/bin, /lib, /lib64, and /sbin are symlinks to /usr/bin, >> /usr/lib, /usr/lib64, and /usr/sbin) although I do not yet have >> the sbin -> bin merge yet. > > FWIW I decided the single /usr -> . symlink was simpler, and > besides, I liked the shorter direct paths. =:^) And I did the /usr > merge first, thinking I wanted to keep the bin/sbin distinction at > first, until sometime later I decided to simplify my PATH var to > remove /usr, and realized I had sbin in my normal user's PATH too. > Completing the merge would/did allow me to simplify PATH even > further, and since I has sbin in my normal user's PATH, there > really wasn't a reason to keep them separate at that point, and I > was already comfortable with merged bins by then anyway, so it > wasn't much of a stretch at all. > >> I added a post_src_install and post_pkg_preinst hook in my >> /etc/portage/bashrc to ensure that there are no conflicts before >> the package is merged and a pre_pkg_setup hook to disarm >> gen_usr_ldscript (so as not to create a conflict). > > That's all unnecessary, because as I said, in general portage "just > works" with the merge now, since it's designed to work with pretty > much /any/ strange site-specific symlinking local gentoo admins > might throw at it, altho I expect the ldcache stuff is still doing > a bunch of extra work by going over all the dirs that are actually > the same thing, and I suspect revdep-rebuild (which I still run > religiously after every @world update) is doing a bunch of extra > scanning too. But as I'm on SSD the extra filesystem IO isn't a > big issue, meaning it's simply the CPU cycle cost, and so far > simply spending the extra CPU cycles has been cheaper for me than > actually researching what I might do about it, so... > That is good to know. I did, however test when a package installs two (different) regular files into paths that end up symlinked, and found that portage does break in that case (as the only sensible option at that point is to fail, as something will be lost in either case). - -- Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTtQDKAAoJELHSF2kinlg4eIIP/0Jmia/151IPAAt3oG7OalVr 1SyUSdAchM/cCb6m8uf3BDPIxMQa704Zh/TKd3wAxz64BJGmJtDmEBlAq+04nXnw UFB+dJVJsphN/X/jS7iln1tVqn8099mntYWG9mjv4nQLXNf6U0H1i9iBQtz+uvi5 9tzO6Ghoen6VvyV7ykI/r2uByI4Y4+anVgXKT2s99akbIWFR9qQuHOHWlcxZxurd QA17Wfnxene7FfpGtsanORvpiKaQamUo75zXlR7l5FydiANH5QKt1Qw5RZIC/k27 PVc+oV2A+7HJVWHrMqEBwwGyn8LokzzX644TpiL17rTHkGa9jYYnsfwO/mIksEh2 O7HzbHyGjD6yUVbY/G3bxUfjpEi0C02DASSlOrHnDsZf4U5joYf9D//jTFQhCkp8 TtPcU7h4HIlyniberknM/WMqQ8B4lnjlCGNcVoaZtqabQ6YtIV+9
Re: [gentoo-dev] new profile layout with flavors and mix-ins
On 07/03/2014 08:18 AM, Joshua Kinard wrote: > On 07/02/2014 13:54, Michał Górny wrote: >> Dnia 2014-07-02, o godz. 10:44:16 > [snip] >> >> I don't feel like we ought to vote on something like this without >> understanding most of the current profiles. And I'm afraid there are >> only few people who have any idea about the current profile >> structure... >> > > I am going to throw this out there and see what people think. Maybe it's > insane, maybe it's not, maybe it's a mix of insane and not-insane. > > Years ago, before we had the current stacking profile design (we were > discussing the current design, actually), I kinda conjured up this "building > blocks" like approach for a profile design. > The idea being that, in /etc/make.conf (or wherever that file is now), you'd > define $PROFILE like this: > > linux-mips o32 uclibc server: > PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0" What about making /etc/portage/make.profile a directory rather than a symlink, having /etc/portage/make.profile/parent to reference all the flavours? Tools that need to respect the /current/ profile should work without any change, and tools that need to respect the /available/ profiles (repoman) already do have a list of profiles to respect (profiles/profiles.desc). So the only missing thing would be the eselect profile module to manage entries of /etc/portage/make.profile/parent, maybe using /usr/portage/profiles/profiles.desc as the source for available flavours. my 2 cents /haubi/
