Re: [gentoo-dev] new profile layout with flavors and mix-ins
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. Basically building on how most of a Gentoo system is pieced together in /etc/make.conf (or wherever that file lives now). A new variable, $PROFILE, would be defined that contains a colon-separated list of profile "blocks" that specifies the nature of the system. Kinda like how $PATH is built. This idea never got any traction, though, and may still not. Quoting from an e-mail I sent months ago to blueness after reading one of his blog posts, here's what I worked out years ago with some updated thinking a few months ago: -- An idea I had at the time, but which never gained any traction, was to use a similar profile layout as we have now, but not treat it like a sequence of directory structures. Instead, the idea was to have it modeled more like how $PATH is built up from discrete components. So instead of something like this: /usr/portage/profiles/base /usr/portage/profiles/default/linux /usr/portage/profiles/arch/base /usr/portage/profiles/features/multilib /usr/portage/profiles/features/multilib/lib32 /usr/portage/profiles/arch/amd64 /usr/portage/profiles/releases /usr/portage/profiles/eapi-5-files /usr/portage/profiles/releases/13.0 /usr/portage/profiles/hardened/linux /usr/portage/profiles/hardened/linux/amd64 /usr/portage/profiles/targets/desktop /usr/portage/profiles/hardened/linux/amd64/destkop You would have a layout in /usr/portage/profiles look like this instead (btw, this is from long-term memory, so some things might be off from my original idea way back when): arch/ base/desktops/ |-amd64/ |-e17/ |-arm/ |-kde/ |-mips/ |-gnome/ |-sparc/ |-xfce/ |-x86/ eapi/ kernel/libc/ |-3/ |-freebsd/ |-glibc |-4/ |-linux/ |-uclibc |-5/ |-musl |-6/ |-freebsd options/ releases/ roles/ |-hardened/ |-11.0/|-desktop/ |-multilib/ |-12.0/|-firewall/ |-13.0/|-ids/ |-freebsd-9.2/ |-router/ |-server/ servers/ subarch/ |-dns/|-mips-o32 |-file/ |-mips-n32 |-mail/ |-sparc-v8 |-www/|-amd64-x32 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" linux-amd64/x86_64/x64 glibc hardened 13.0 KDE desktop: PROFILE="base:kernel/linux:arch/amd64:libc/glibc:roles/desktop:options/hardened:desktops/kde:releases/13.0" freebsd-amd64 9.2 firewall: PROFILE="base:kernel/freebsd:arch/amd64:libc/freebsd:roles/firewall:releases/freebsd-9.2" 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). 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 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. 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
[gentoo-dev] About DELL ALPS touchpad
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. I installed the synaptics, and kdemsc_touchpad, when I am trying to setup the touchpad, it seems synaptics driver is not loaded automaticly, it modprobe it manualy, but doestnot work. I searched Google, it seems ALSP is not very much compatible with synaptics driver, I want to ask here whether someone can help me with this. 2014-07-03 Thanks & Best Regards. 陶治江 | TAO Zhijiang
[gentoo-dev] Re: Making a common sub-profile for no-multilib
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... > The only two packages I have installed that I had to modify to make this > work were coreutils (as noted above) and plymouth. I did find one package with a specific post-install quirk, that was there to work around a binary move from many years ago, that ended up specifically removing the binary after portage had done its thing and actually put the binary in place instead of the symlink, but that binary wasn't a system-critical binary (dircolors, FWIW, pkg=coreutils), and upon investigation and filing a bug suggesting to test that it was a symlink, not the actual binary removed, the maintainer (vapier) decided that the reason that particular post-install quirk was there was far enough back in history he could just remove it from the ebuild. I didn't check whether he removed it from stable, but at least leading ~arch coreutils doesn't have that quirk any longer, and leaves dircolors alone. FWIW, https://bugs.gentoo.org/show_bug.cgi?id=509596 The only other relatively minor irritation that remains is a portage bug, but as I said it's relatively minor as it doesn't affec
[gentoo-dev] Re: Making a common sub-profile for no-multilib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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. I'm not saying that we need to >> implement any of that stuff completely - but when planning the >> profile layout we should at least consider whether it will handle >> things like this in the future. Should some types of profiles be >> only additive? Etc... > > 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. 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. 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). The only two packages I have installed that I had to modify to make this work were coreutils (as noted above) and plymouth. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTtJCTAAoJELHSF2kinlg41W0P/19TAJErj3y7eMFGJG2BMVIM TtAj2wM+whB0Md1+TGypFS0ESO+hJAxNyyuIT215afRIqZJgYjZG5NZCnmygI71t 9das1k2JHn+PRO5KSZcw3Z3VcpspzADTwR+avaxiqRuslzyTvAYrsPj+7oQd6iDp 4XzDKFSEh2hNJHUQUQ3eT5NxlJNQu9uxKLc4aM+1/GImlSAVbbiKHUHWy3njSVWN twFkQJ59IHod9aZgn0txydd9hhMr43Et6uDJywjGuIeVQncAO/eBvT9hRE5tB3aN x/pd1Dcf0V5FTN/459kcoRwTBQ2k3quhGJBeSSGLUwNlTjdOWDbqU5HcgOf0d7v4 NXMIOr95ung3LgeqCyZU5S4XTyoh9w/nZRXuSTYL0sQL3IxffLRkVPcvis02cY6a jZaSAwkVkPhyAGkV0QxMsfhEP9+2wdtB7JMc28kslO0kGpdV5Oa8ES+QqnwVXgi7 umB+5D4IjTDK6uPcM5K5p+8wKWcsFMvn5X/+3Fh49S6KDiWZRsjq45pHC7+5lC0p S8EJb8XybieRvQsVGo8NfgucvRQFbeUn+BaUfztoNRvKG3NxsnxRJ+JycK9bi1pj znu7YKmCZMmt8PurliQPKQ6vtPjFQK19gZZf72zTVBycc2hdaKnbowAV0rBgTETN +8xryIRBNfISkUIjEip/ =Muzz -END PGP SIGNATURE-
Re: [gentoo-dev] new profile layout with flavors and mix-ins
On Wed, Jul 2, 2014 at 3:19 PM, Rick "Zero_Chaos" Farina wrote: > > On 07/02/2014 03:07 PM, Anthony G. Basile wrote: >> >> 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. >> > I agree entirely. Right now the mixin style profiles are not supported > in gentoo _at_all_, and if no one ever works on that, then we will never > support it. I will work on the first step in a long road, that's all > I'm talking about here. I agree. I think getting support in all the tools for multiple profiles is a good start. Volunteers can then begin working on profiles that dis-entangle things. A first step might be to just rip out the desktop/etc categories, leaving the mess of arch/hardened/kernel/etc. Then we try to keep peeling back the layers. We don't have to get there in one step, nor do we have to release anything to the general public before it is finished. We might not end up with completely flat profiles - the goal is to end up in a better place than we are now, and perhaps we can make more progress later. Rich
Re: [gentoo-dev] new profile layout with flavors and mix-ins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/02/2014 03:07 PM, Anthony G. Basile wrote: > On 07/02/14 14:41, Rick "Zero_Chaos" Farina wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 07/02/2014 02:10 PM, Rich Freeman wrote: >>> On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote: 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... >>> No argument there. >>> >>> We may very well still end up with something hierarchical, but we can >>> at least limit that to the parts of the profile where it matters. >>> Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be >>> interdependent. However, that still gets rid of need to deal with >>> desktop environments, init systems, arguments over what belongs in >>> @system, and so on. We could have a blocker mechanism to keep people >>> from mixing systemd with BSD, or we could just let people shoot >>> themselves in the foot. >>> >>> Sounds like a good time to start reverse engineering the profiles... >>> >> 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. >> >> - -Zero >> -BEGIN PGP SIGNATURE- >> > > 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. > I agree entirely. Right now the mixin style profiles are not supported in gentoo _at_all_, and if no one ever works on that, then we will never support it. I will work on the first step in a long road, that's all I'm talking about here. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTtFtTAAoJEKXdFCfdEflKDk0P/j6F/7ivY2HkbRV3Y60YiahE IbzwrZ7wQCap5sAELOtQaXTyTHuyTLkTrAqqM/r+/8a0/Ebm67yEALbzE4IOMAFL DoiS7mg0FZeq2Bm8AGKtYwmBHAiIYbGWX+XgxuFbwpHz4uilsVhQH9+e+rFlu6SN 22BDmW6tQSDL5a3C2Coqoq/KVH/heHu43w6/TuZmVVByLcABHrEG/KOnLRHSGfwF ps+R3UaMmFA9w6VGqGxlOXuIbF+cp//xOTfqmetYfe5kkOsls/ZAKou1MMCrCSI7 j6oJbH5q5Gn5W6vxctf8PJPI8R5NWZBOFwvDgkeJ9Zcsqhsinb19QQFVkG6HOrt1 2nSTOP9U/5d0wYn9P7cNgQsXjg8P2KwHfPXG8qZ8jx1CSM0T2bY4csjALgqAmvpz ATa9XbpGmcRMoldqiVZEVN2EqL1NWVXo0i490Y51noiLpNSiSO2XT4lbIj1fae+i yxt6RuJ04QltsQKKzH3swCqgFBUZmNZe2h0p0dt+GFOl9Pg0oa3QX3eGR0msgmEy Qti0JRZwQJrHkDCSzZP0OAI2RZDj5XxmhS1brTTvb7LnxFecWR760LfQ/bzJgqno M800gZKrJ9AjzC8lvzqWQrd39W4VYhcDn19S5zHtBPb3KK/4jC9J1TVwwgzbW7jb z6ytQ2biVKhkBPrec5tf =2WzO -END PGP SIGNATURE-
Re: [gentoo-dev] new profile layout with flavors and mix-ins
On 07/02/14 14:41, Rick "Zero_Chaos" Farina wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/02/2014 02:10 PM, Rich Freeman wrote: On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote: 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... No argument there. We may very well still end up with something hierarchical, but we can at least limit that to the parts of the profile where it matters. Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be interdependent. However, that still gets rid of need to deal with desktop environments, init systems, arguments over what belongs in @system, and so on. We could have a blocker mechanism to keep people from mixing systemd with BSD, or we could just let people shoot themselves in the foot. Sounds like a good time to start reverse engineering the profiles... 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. - -Zero -BEGIN PGP SIGNATURE- 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. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] new profile layout with flavors and mix-ins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/02/2014 02:10 PM, Rich Freeman wrote: > On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote: >> 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... > > No argument there. > > We may very well still end up with something hierarchical, but we can > at least limit that to the parts of the profile where it matters. > Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be > interdependent. However, that still gets rid of need to deal with > desktop environments, init systems, arguments over what belongs in > @system, and so on. We could have a blocker mechanism to keep people > from mixing systemd with BSD, or we could just let people shoot > themselves in the foot. > > Sounds like a good time to start reverse engineering the profiles... > 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. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTtFI/AAoJEKXdFCfdEflK7GYP/0GS+Sh4odpHNMUfNfyU+q7F HpNuJ/OSnnNBRol4dDjcvhE3RFxIqU1DkC1atsl19K14vJXk+JBSKw8fgV4J6ous 0uOYqN472Noy7NxzmrbfrlR1PePG1b878ZpOMbGce1dgMfamoDwv48IjfcSwakcv 6HSy09xfr5O8xG+cSBqyVmaiDxsPHPQwv1s+/JUpcadBr4AmD7qc7yTZ5QjKJoIg o1eL/j//KiYxQywoQ1udqXwx/beBgYMQB4R5Vu4d1BBtIttnJdTHCZdAv6Uoi686 x4VWuvBPDaILojyhIYqpoMbKAu/c/AFRFkpFZXFVl5kWyolw/YuBg4RL21qecDvp 9qyoQFCzIWCSzXl747O4iFYjS1ACbMSUXOSDEecvnYuCsjvI+bpJT2pWVlAxIMUH 79IgKTu0+1LETl/lEeMN8ccrG8R2hhrYCxxyTw1nZfevN9SPC88RwEIcuBwVFHC3 NC7fpxKzDFy2+0ixBnLCQA7ICnvV5crF2Tt4/bg9Hbp2UP/QMmhxIwUbceRSDXc5 3c8nqsUGavLX8K9IE3IlI5ZYutmYJgJwfqX8yA6wdOeZgPvH59gypnBYFKJjO2DQ JZE+lVZ4vXLmgw1WTAdRUYFhLEqesioCAVH7Bm7gUnccCeWE4PFHr15BGhdh/Mw9 L88DkCnfAbLcSHRJS0Cx =iBrl -END PGP SIGNATURE-
Re: [gentoo-dev] new profile layout with flavors and mix-ins
On Wed, Jul 2, 2014 at 2:32 PM, Anthony G. Basile wrote: > Shallow profiles avoid this. Also "features" avoid this (the > closest thing we have to mix-ins) provided they operate on a set of > flags/packages orthogonal to the rest of the stack. You then have shallow > base and you can add as many features as you like in, in any order, > confident that one will not clobber stuff from another since each feature is > well separated. That was my thinking as well. If we had categories of profiles and set up the rules to try to keep things orthogonal then we're going to be better off. Also, things like feature profiles should try to be additive in nature. Rich
Re: [gentoo-dev] new profile layout with flavors and mix-ins
On 07/02/14 14:10, Rich Freeman wrote: On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote: 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... No argument there. We may very well still end up with something hierarchical, but we can at least limit that to the parts of the profile where it matters. Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be interdependent. However, that still gets rid of need to deal with desktop environments, init systems, arguments over what belongs in @system, and so on. We could have a blocker mechanism to keep people from mixing systemd with BSD, or we could just let people shoot themselves in the foot. Sounds like a good time to start reverse engineering the profiles... Rich The way the profiles stack via the parent file makes them difficult to work with if they get to any significant depth. Here, for example, is the stacking for default/linux/mips/13.0/mipsel/multilib/n32 /usr/portage/profiles/base /usr/portage/profiles/default/linux */usr/portage/profiles/arch/base */usr/portage/profiles/arch/mips */usr/portage/profiles/default/linux/mips /usr/portage/profiles/releases /usr/portage/profiles/releases/13.0 /usr/portage/profiles/default/linux/mips/13.0 */usr/portage/profiles/arch/base */usr/portage/profiles/arch/mips */usr/portage/profiles/arch/mips/mipsel /usr/portage/profiles/default/linux/mips/13.0/mipsel */usr/portage/profiles/arch/base */usr/portage/profiles/arch/mips */usr/portage/profiles/arch/mips/mipsel /usr/portage/profiles/arch/mips/mipsel/mips64el /usr/portage/profiles/features/multilib /usr/portage/profiles/arch/mips/mipsel/mips64el/multilib /usr/portage/profiles/arch/mips/mipsel/mips64el/multilib/n32 /usr/portage/profiles/default/linux/mips/13.0/mipsel/multilib/n32 I put asterisks there to point out a pattern that gets pulled in repeatedly. Sometimes this isn't a problem but sometimes this leads to asserting something, then reverting it, then asserting it again. In the ancient selinux profiles (circa 2009) this meant you couldn't have a no-mutlilib amd64 system. Shallow profiles avoid this. Also "features" avoid this (the closest thing we have to mix-ins) provided they operate on a set of flags/packages orthogonal to the rest of the stack. You then have shallow base and you can add as many features as you like in, in any order, confident that one will not clobber stuff from another since each feature is well separated. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Re: Making a common sub-profile for no-multilib
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. I'm not saying that we need to implement any of that > stuff completely - but when planning the profile layout we should at > least consider whether it will handle things like this in the future. > Should some types of profiles be only additive? Etc... 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. -- 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 Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote: > 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... No argument there. We may very well still end up with something hierarchical, but we can at least limit that to the parts of the profile where it matters. Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be interdependent. However, that still gets rid of need to deal with desktop environments, init systems, arguments over what belongs in @system, and so on. We could have a blocker mechanism to keep people from mixing systemd with BSD, or we could just let people shoot themselves in the foot. Sounds like a good time to start reverse engineering the profiles... Rich
Re: [gentoo-dev] package.mask vs ~arch
On Wed, Jul 2, 2014 at 1:56 PM, Tom Wijsman wrote: > That is an edge case; it's somewhat hard to maintain a package if you > can't test it, and there are occasions (eg. Amazon EC2 related > packages) where this is indeed needed. I don't see a need to introduce > that masked though; but again, it depends on how edgy it is... > No argument there. I think that use of package masks for testing-related purposes should be rare and short-lived. I just don't think that banning them entirely is the right solution. If they're done right they probably shouldn't be noticed by the majority. Rich
Re: [gentoo-dev] package.mask vs ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 30 Jun 2014 15:44:21 -0400 Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 30/06/14 03:14 PM, Tom Wijsman wrote: > > > Setting up an overlay for this and poking a stick at a few > > developers to try it out could help as an intermediary test, to > > ensure that you don't break every ~arch user in the progress. > > Better than "all or nothing"... > > Or i can just use the same stick to poke them about the p.masked > version in the tree. :) > > All of this just means, to me, that as long as the packages indeed are > actively being pursued for testing, I think it's still fine to use > package.mask. However, if things aren't being actively tested (ie > they've been forgotten about) then probably whomever added the mask > should be pinged relentlessly about it until it's resolved one way or > another. At least, I would find it perfectly acceptable to being > pinged on any mask I've left rotting in the tree. +1 One could say that ensuring it is tested is part of the workflow; and then I don't mean your own testing, but inviting others to do so. - -- 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 iQEcBAEBAgAGBQJTtEguAAoJEPWZc8roOL/QKKoIAI0KlFu28ri4KB7gAWJAQXe/ cgvNYy7Gy5kwbl9pagCSP9NhBO0VZ4LNRZIMY0OqOhv/fs9pM2+tdKOV3c/f+8mo 3PvE2zW6+U0NUDBeYDmSdRoCVuFecuZiLk9y8gciGLIipLVZ9jaIwW2N5l/jvT69 KZFLLRgoFvLeXFvg05LUbZgKlMsvpi3DJh0HWG2l0CCuGAw+vNSnFqviPyFWnVCP mhZZuYh3Xwf9/yyrWwKHFY+JjlHD2aqCd1rO9q7Ght/Wbi1knzBt4PE+kgj7xTSo 7BVTEuskcAq4yU9wvmxUYKIyGGwnjmVD5L+fK+LcVnWp4A8zwQG6bk6opiSIFN0= =R2Cc -END PGP SIGNATURE-
Re: [gentoo-dev] package.mask vs ~arch
On Mon, 30 Jun 2014 15:19:59 -0400 Rich Freeman wrote: > On Mon, Jun 30, 2014 at 3:11 PM, Tom Wijsman > wrote: > > > > A test of a package to determine whether it appears to be working > > OK or whether it destructs your system isn't too much asked for; if > > it works it can then be ~arch tested, if it breaks you have a bug # > > for p.mask. > > > > If someone can't test it at all, why was it added in the first > > place? > > So that it can be tested? Maybe the maintainer doesn't have the > ability to test the package (might require special hardware). Maybe > the maintainer doesn't have the time to test it right away, but wants > to allow others to do so (especially if others show an interest). That is an edge case; it's somewhat hard to maintain a package if you can't test it, and there are occasions (eg. Amazon EC2 related packages) where this is indeed needed. I don't see a need to introduce that masked though; but again, it depends on how edgy it is... > Sure, I can set up yet another overlay, which will be empty 99% of the > time. But, what is the harm in just using a mask? I've yet to leave > one sitting around for years (well, not for testing at least). No problem with that if it is for a safe introduction, although I'm not quite sure how much that really invites actual testing; however it's not about that, everything that stays longer forms the problem. -- 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 signature.asc Description: PGP signature
Re: [gentoo-dev] new profile layout with flavors and mix-ins
Dnia 2014-07-02, o godz. 10:44:16
William Hubbs napisał(a):
> All,
>
> I'm moving to a new thread since the discussion has moved away from just
> a sub profile for no-multilib.
>
> On Wed, Jul 02, 2014 at 09:30:50AM -0400, Rich Freeman wrote:
> > On Wed, Jun 25, 2014 at 4:01 PM, Andreas K. Huettel
> > wrote:
> > > Am Mittwoch 25 Juni 2014, 15:11:40 schrieb Rich Freeman:
> > >> On Wed, Jun 25, 2014 at 2:44 PM, Michał Górny wrote:
> > >> > Long story short, doing anything to Gentoo profiles is utter pain
> > >> > and comes with random breakage guarantee. Therefore, I'm asking -- nuke
> > >> > those damn profiles, and start over! The current situation is
> > >> > completely unmaintainable.
> > >>
> > >> ++
> > >>
> > >> But, would it make sense to just go the Funtoo route with "mix-ins."
> > > ++
> > >
> > > this is what we've been just discussing on the irc channel
> >
> > So, not wanting this to die on the vine.
> >
> > If we did the mix-in approach, would we just follow the example of Funtoo?
> >
> > They use an arch profile, a stability profile (~arch vs arch), a
> > "flavor" profile (core, minimal, desktop), and then users can layer as
> > much other stuff on top of that as they want (gnome, kde, multimedia,
> > etc).
>
> I think this could work for us as well, or something similar anyway.
>
> For those who are curious, I am including the link to the flavors and
> mix-ins descriptions from the funtoo site. [1]
It's not that easy. As you can see on that site, they're supporting
much less variants than Gentoo does. In particular, they don't seem to
support non-GNU/Linux at all. No Prefix, no Hardened, no FreeBSD.
I was thinking about modularization a bit and the main issue is
handling intersecting profiles. As you can see in Funtoo, it already
starts with the 'build' flavor -- they're pretty much applying a cheap
hack (ACCEPT_KEYWORDS="${ARCH}") but such hacks can't cover all our
needs.
A simple example is CHOST. The value of CHOST depends on the arch,
often ABI, kernel, libc. Of course, we could hack this around by
creating some intermediate variables and merging them afterwards.
But not everything can be hacked around like this.
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...
> > Do we want to do things the same way?
> >
> > Some things to think about include multilib (just another arch?),
> > systemd, and usr-merge. I'm not saying that we need to implement any
> > of that stuff completely - but when planning the profile layout we
> > should at least consider whether it will handle things like this in
> > the future. Should some types of profiles be only additive? Etc...
>
> I see systemd and multilib as mix-ins, like the ones you mentioned
> above.
Multilib won't work as Funtoo-style mix-in for the simple reason it
relies on heavily on the architecture in use.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] new profile layout with flavors and mix-ins
All, I'm moving to a new thread since the discussion has moved away from just a sub profile for no-multilib. On Wed, Jul 02, 2014 at 09:30:50AM -0400, Rich Freeman wrote: > On Wed, Jun 25, 2014 at 4:01 PM, Andreas K. Huettel > wrote: > > Am Mittwoch 25 Juni 2014, 15:11:40 schrieb Rich Freeman: > >> On Wed, Jun 25, 2014 at 2:44 PM, Michał Górny wrote: > >> > Long story short, doing anything to Gentoo profiles is utter pain > >> > and comes with random breakage guarantee. Therefore, I'm asking -- nuke > >> > those damn profiles, and start over! The current situation is > >> > completely unmaintainable. > >> > >> ++ > >> > >> But, would it make sense to just go the Funtoo route with "mix-ins." > > ++ > > > > this is what we've been just discussing on the irc channel > > So, not wanting this to die on the vine. > > If we did the mix-in approach, would we just follow the example of Funtoo? > > They use an arch profile, a stability profile (~arch vs arch), a > "flavor" profile (core, minimal, desktop), and then users can layer as > much other stuff on top of that as they want (gnome, kde, multimedia, > etc). I think this could work for us as well, or something similar anyway. For those who are curious, I am including the link to the flavors and mix-ins descriptions from the funtoo site. [1] > > Do we want to do things the same way? > > Some things to think about include multilib (just another arch?), > systemd, and usr-merge. I'm not saying that we need to implement any > of that stuff completely - but when planning the profile layout we > should at least consider whether it will handle things like this in > the future. Should some types of profiles be only additive? Etc... I see systemd and multilib as mix-ins, like the ones you mentioned above. It is funny that you mention usr-merge. I don't want to get into a big debate on it on this thread, so for now I'll just say that I don't see that as affecting the profile structure at all. William [1] http://www.funtoo.org/Flavors_and_Mix-ins signature.asc Description: Digital signature
Re: Re: [gentoo-dev] Making a common sub-profile for no-multilib
On Wed, Jun 25, 2014 at 4:01 PM, Andreas K. Huettel wrote: > Am Mittwoch 25 Juni 2014, 15:11:40 schrieb Rich Freeman: >> On Wed, Jun 25, 2014 at 2:44 PM, Michał Górny wrote: >> > Long story short, doing anything to Gentoo profiles is utter pain >> > and comes with random breakage guarantee. Therefore, I'm asking -- nuke >> > those damn profiles, and start over! The current situation is >> > completely unmaintainable. >> >> ++ >> >> But, would it make sense to just go the Funtoo route with "mix-ins." > ++ > > this is what we've been just discussing on the irc channel So, not wanting this to die on the vine. If we did the mix-in approach, would we just follow the example of Funtoo? They use an arch profile, a stability profile (~arch vs arch), a "flavor" profile (core, minimal, desktop), and then users can layer as much other stuff on top of that as they want (gnome, kde, multimedia, etc). Do we want to do things the same way? Some things to think about include multilib (just another arch?), systemd, and usr-merge. I'm not saying that we need to implement any of that stuff completely - but when planning the profile layout we should at least consider whether it will handle things like this in the future. Should some types of profiles be only additive? Etc... Rich
Re: [gentoo-dev] package.mask vs ~arch
Rich Freeman wrote: > If we're going to define ~arch as basically stable, and arch as > out-of-date, then we might as well drop keywords entirely. I actually don't think that would be such a bad thing. I only consider ~arch relevant, because it is the closest to upstream. I want the distribution I use to be as thin as possible; the value it adds is administrative - and the Gentoo packages and tools are fantastic. \o/ The thicker a distribution is, the larger a gap between users and upstream it creates, which inconveniences *both* users and upstream, because users have to wait for new code, and upstreams have to deal with lots of known and possibly fixed bugs. The ideal would be only live ebuilds, but for now we have no precise technology for synchronization. Version numbers are both blunt and arbitrary. //Peter
Re: [gentoo-dev] Multilib project newsletter #n
Dnia 2014-07-02, o godz. 07:24:09 Ulrich Mueller napisał(a): > > On Tue, 01 Jul 2014, Ian Stakenvicius wrote: > > > On 01/07/14 06:44 PM, Ciaran McCreesh wrote: > >>> || ( amd64? ( > >> > >> I thought we were trying to discourage that abomination... > > > It's still necessary, unfortunately, until such time as everything > > in the tree no longer needs/depends on the emul-* packages (see news > > item #8 for progress). Otherwise, end-users would end up with > > dependency collisions. > > Sure, the second block is needed, but the point is that foo? ( ) > conditionals inside a || ( ) group should be avoided. > > I wonder if the dependency couldn't be written like this, without the > amd64? () conditional: > > || ( > ( > >=dev-libs/glib-2.34.3:2[abi_x86_32(-)] > >=virtual/opengl-7.0-r1[abi_x86_32(-)] > ) > ( > app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] > app-emulation/emul-linux-x86-opengl[-abi_x86_32(-)] > ) > ) > > emul-linux-x86-* doesn't have keywords other than amd64, so it won't > match on non-amd64 anyway. It would but I wanted to be on the safe side when one of the developers broke deps. I really don't want autounmask to try to keyword emul-linux-x86 on x86 :). But maybe '-*' in the ebuild is enough. As a note, something like this won't work properly because of portage's broken dep resolver: || ( dev-libs/foo[abi_x86_32(-)] dev-libs/foo[abi_ppc_32(-)] ) -- Best regards, Michał Górny signature.asc Description: PGP signature
