Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...
On Sun, 29 Jan 2017 15:11:43 +0100 Róbert Čerňanskýwrote: > If I may add a user opinion. I agree with you but I would choose > different solution for user-friendliness. Instead of _adding_ > interactivity to PM I would _remove_ it. So if there would be > multiple choices the user would not be prompted, but some default > option would be selected by PM. To the user, such behaviour would be > similar to current handling of virtuals - if a package depends on a > virtual the user is not prompted to make a choice but the default is > selected instead. This. Exactly this. In fact, I would go even further. Let’s look at two parallel situations. Situation 1: app-cat/foo DEPENDs on dev-libs/bar. I want app-cat/foo. I emerge app-cat/foo. Portage automatically installs dev-libs/bar. It doesn’t require me to say anything about dev-libs/bar (though if I ask to confirm before starting the build then it will mention it). I never have to add dev-libs/bar to any user-maintained files (i.e. /etc/portage/* or /var/lib/portage/world). If I ever uninstall app-cat/foo, then dev-libs/bar will go away on its own when I depclean. Situation 2: app-cat/foo DEPENDs on dev-libs/bar[baz]. I want app-cat/foo. I emerge app-cat/foo. Portage… fails. It requires me to manually add “dev-libs/bar baz” to /etc/portage/package.use/* (it will do it itself, if desired, due to autounmask, but of course it puts it in the wrong file because I like to keep things organized with multiple files). That setting goes on living in /etc/portage, a user-maintained area, forever. If I ever uninstall app-cat/foo, baz will stay set until I eventually get around to slogging through /etc/portage/package.use looking for things I can turn off because I don’t need them any more. Why? It’s just another dependency. Why does DEPEND="dev-libs/bar" work so beautifully but DEPEND="dev-libs/bar[baz]" work so horribly? If I haven’t explicitly said I want baz, and I haven’t explicitly said I *don’t* want baz, and enabling baz doesn’t conflict with any other packages I have installed, Portage should just rebuild dev-libs/bar with USE=+baz. If I eventually uninstall app-cat/foo, something like depclean should reinstall dev-libs/bar with USE=-baz. Just like all the other dependencies, if I don’t care to make a manual choice, it should be automatic and dynamic. -- Christopher Head pgpdkiVtAMXgB.pgp Description: OpenPGP digital signature
[gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)
Hello, I am working towards having a clean deptree for arm64 and afterwards marking the non-hardened 5 arm64 profiles stable (or 4 - I don't see value in the developer profile without the desktop specific subprofiles, until there are mix-ins). This e-mail is meant to make sure there are no other pre-requisites for just flipping the switch in profiles.desc from exp to stable, and to express that intent and garner any hands-on help. Also some eyes on the profiles (profiles/arch/arm64/*) would be useful, especially from those who knows how all these CHOST/LIBDIR and other things need to be, to make sure these are all right before the profiles go stable. Currently my plan is to solve all the deptree issues by mostly stable use masks where needed (the stage building stable keywords haven't kept the deptree in mind so far, just for what USE flags are enabled for stage building), and keywording ~arm64 or use.mask/package.use.mask'ing to fix the ~arm64 deptree too (depending on if I want it keyworded immediately, or delay for future consideration and fix the deptree by use masks till then). I'm having the CI hamsters spin for this at https://github.com/gentoo/gentoo/pull/3622 Yes, there is quite some work to do, but this e-mail is meant to get any necessary formalities out of the way in parallel, so we can get the switch flipped right after instead of discussing it then, and not continue a chasing game due to repoman not telling to file a KEYWORDREQ for us for new deps. Note that there is no arm64 project as of yet, it's been worked on to some capacity as part of arm project, which I believe to be a bit confusing (albeit similar to ppc/ppc64), but also a bit daunting with the arm4/5/6/7/vfp/neon/etc combination explosion stuff in arm32 land (so I think it's good to have a clean break there with project documentation pages, people involvement, etc). I haven't been able to convince steev as of yet about this and haven't exercised any project creation rights myself yet :D Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Guidelines for IUSE defaults
On Fri, 3 Feb 2017 19:59:34 -0500 Ian Stakenviciuswrote: > On 03/02/17 02:37 PM, Michael Orlitzky wrote: > > On 02/03/2017 10:30 AM, Ian Stakenvicius wrote: > >> > >> ok you lost me. Could you provide an explicit example of what you > >> would want to see enabled in the profile (while everything else is > >> disabled) that you don't get when USE="-*" is set? > > > > USE="hardened pax_kernel ..." > > > > ok, so global flags that are never modified via IUSE defaults. It > still looks to me like all you need to do to get what you want is swap > the order of 'conf' and 'defaults' in USE_ORDER? (man make.conf) > > > > > I don't want to turn off all IUSE defaults. Since we have no policy > > on what IUSE defaults should be used for, half of them are > > important, and the other half are junk. I don't want to disable the > > ones that are critical for the package to function, and I don't > > want to disable the ones that satisfy an (otherwise unsatisfied) > > REQUIRED_USE constraint. > > And herein lies the crux. "Junk" is your definition, but it's not > necessarily the maintainer's definition. "Critical for the package to > function" is entirely dependent on what you expect to use the package > for. If you want to disable everything optional then USE="-*" will do > that, and really all you should be losing is the ability to have > REQUIRED_USE auto-resolve based on the IUSE defaults that are set. > However, even in that case, it seems likely that you may well want to > use a different option to resolve a REQUIRED_USE conflict to ensure > your minimalist install than is the default that the maintainer > provided. > I think the current policy of "maintainer's discretion" is probably the only reasonable way to approach IUSE defaults. Attempting to dictate some policy based on differing definitions of what is acceptable or not is just a path to a lot of pain for very little gain. I don't think that there are a very large proportion of people who want some sort of "minimal" system, sacrificing basic, expected functionality (as say "-readline" on app-shells/bash would do) in the default configuration . Leaving the IUSE defaults up to the maintainer allows said maintainer to select what they consider reasonable defaults.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 03/02/17 02:37 PM, Michael Orlitzky wrote: > On 02/03/2017 10:30 AM, Ian Stakenvicius wrote: >> >> ok you lost me. Could you provide an explicit example of what you >> would want to see enabled in the profile (while everything else is >> disabled) that you don't get when USE="-*" is set? > > USE="hardened pax_kernel ..." > ok, so global flags that are never modified via IUSE defaults. It still looks to me like all you need to do to get what you want is swap the order of 'conf' and 'defaults' in USE_ORDER? (man make.conf) > > I don't want to turn off all IUSE defaults. Since we have no policy on > what IUSE defaults should be used for, half of them are important, and > the other half are junk. I don't want to disable the ones that are > critical for the package to function, and I don't want to disable the > ones that satisfy an (otherwise unsatisfied) REQUIRED_USE constraint. > And herein lies the crux. "Junk" is your definition, but it's not necessarily the maintainer's definition. "Critical for the package to function" is entirely dependent on what you expect to use the package for. If you want to disable everything optional then USE="-*" will do that, and really all you should be losing is the ability to have REQUIRED_USE auto-resolve based on the IUSE defaults that are set. However, even in that case, it seems likely that you may well want to use a different option to resolve a REQUIRED_USE conflict to ensure your minimalist install than is the default that the maintainer provided. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, 2 Feb 2017 18:01:54 -0600 Gordon Petteywrote: > If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't > allow any granularity. Another variable USE_PROFILE should be added > analogue to DEPENDS: > IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme > annoyingUpstreamDefault" > USE_PROFILE=" > desktop? ( pulseaudio ) > gtk? ( gtk-theme ) > gnome? ( @gtk gnome-keyring) > kde? ( @qt kwallet ) > qt? ( qt-theme ) > upstream? ( annoyingUpstreamDefault ) > " This is the way I'd suggest going as well. Mostly, because needless double-accounting by communicating this same information to a global profile seems like creating work without benefit. I'd probably suggest something like this, but with a restriction that every "foo?" on the left hand side being a defined global term. Especially considering that USE="-*" doesn't necessarily give you "less dependencies", in the case of dev-util/pkgconfig, USE="-*" aligns with the existing (default) mechanic of USE="-internal-glib", and so a "minimal system" would either a. Prefer dev-util/pkgconf which doesn't require glib at all ( bug #606260 [1] ) b. Prefer USE="internal-glib" Clearly given bug #606260, our current mechanism of following upstream defaults is not ideal for minimal systems, even though its fine for 99.99% of users. Hence, I'd prefer something akin to: virtual/pkgconfig: RDEPEND=" profile:minimal? ( || ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] dev-util/pkgconfig ) ) +profile:upstream? ( || ( dev-util/pkgconfig dev-util/pkgconf ) ) " Granted here I'm stepping slightly outside the conversation of USE defaults, because this is a related system where the concepts of defaults are present, but are instead regulated by implicit controls based on what the user has already decided to install. And this example suggested usage is a bit dodgy because it could be abused by people using profiles instead of useflags to control behaviour. However: IUSE="minimal" IUSE_PROFILES=" minimal? ( minimal ) " RDEPEND=" minimal? ( || ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] dev-util/pkgconfig ) ) !minimal? ( || ( dev-util/pkgconfig dev-util/pkgconf ) ) " Would be less abusey. Also, this approach in general means instead of needing repoman to compute the interaction of x for all(@profiles), it only needs to compute the interactions for Profile X x Profile Y for union(x.profiles y.profiles) ( Though personally I don't think repoman needs to compute anything for defaults, I just saw somebody else mention this in a different part of this thread and it confused me. However, it *could* be useful to be able to ensure cohesion within a single chosen profile name, being able to state "If you set your profile to X and don't change anything in package.use, everything that has profile X will be installable as-is" ) And this of course brings into observation my favourite negative-useflag, for which USE="-*" will have the opposite effect to that you intend. __ SIMPLIFIED __ # May contain only the possible useflags, not setting defaults IUSE="" # A list of "profilename ? ( assumed defaulted on flags )" # where "profilename" must be a defined profile ID # "profilename" can have a "+" to indicate it is the default profile # if none of the others listed in IUSE_PROFILES matches a user description IUSE_PROFILES="" > @ is already used for sets, so "some other use_profile's set of defined > flags" seems reasonable. It should be additive only, so no +- prefixes > needed (or allowed). If a package is emerged without any USE_PROFILE set, > you might einfo "This package supports was emerged with no use profile. It > supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE > should never have any default selected by an ebuild; if a flag is required > to build, is shouldn't be a flag. You get independent behavior per package > rather than listing every single package that ever existed in > profile/package.use, package behavior actually being with the package > instead of global profiles, and you get rid of the mess of uncustomizable > IUSE="+something" everywhere that makes people like me tend to start off > every new Gentoo install with echo "USE=\"-*\"" >> /etc/portage/make.conf. > Just need to come up with sane naming convention for common possibilities > like kde, gnome, and generic desktop. Personally, I think encouraging people to set profiles on a per-package level fights the cause of this feature in ways that should be governed by USE flags. The real utility of profile-governed defaults is that you should select a given profile, and *everything* should work out of the box *without* needing to change use flags, and repoman should compute how "my profiles defaults expanded into dependencies" would introduce a need to change USE flags on dependencies, and should raise
Re: [gentoo-dev] Guidelines for IUSE defaults
On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote: > On 02/03/2017 01:33 PM, Patrick McLean wrote: > > We might as well go back to before IUSE defaults then. Part of the > > advantage of IUSE defaults is maintainers don't all have to fiddle with > > the profiles, everything can be self-contained in the ebuild. This > > drastically complicates maintenance, having two locations to track and > > change rather than just one. > > You still retain the benefit for IUSE defaults that actually belong in > the base profile, just not for upstream defaults or the ones that you > personally prefer. That is a side effect, as it is more about the package maintainer choosing the defaults. They are not messing with profiles. That base ends up with it is indirect. Otherwise IUSE default flags would have to be per profile rather than in the package. Which would create more work for package maintainers. > > I suspect that there is a small subset > > of people interested in this, and perhaps those people could maintain a > > "minimal" profile that unsets IUSE defaults. > > Then every IUSE default gets recorded twice: once when the maintainer > puts it in the ebuild, and once when I add it (negated) to the minimal > profile. That's a bad design even if we pretend that I can solve the > problem of tracking every IUSE change in the tree. Sorry if its been suggested, I haven't followed every comment. What about some global env variable that could override all default IUSE. That can set in base, and set what ever minimal IUSE flags that are needed. -- William L. Thomson Jr. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 01:33 PM, Patrick McLean wrote: > > We might as well go back to before IUSE defaults then. Part of the > advantage of IUSE defaults is maintainers don't all have to fiddle with > the profiles, everything can be self-contained in the ebuild. This > drastically complicates maintenance, having two locations to track and > change rather than just one. You still retain the benefit for IUSE defaults that actually belong in the base profile, just not for upstream defaults or the ones that you personally prefer. > I suspect that there is a small subset > of people interested in this, and perhaps those people could maintain a > "minimal" profile that unsets IUSE defaults. Then every IUSE default gets recorded twice: once when the maintainer puts it in the ebuild, and once when I add it (negated) to the minimal profile. That's a bad design even if we pretend that I can solve the problem of tracking every IUSE change in the tree. > Also, I would just point out that the particular IUSE default that > you objected to in your original email does not really affect this > "minimalist" ideal that you seem to hold. The "hpn" USE flag on > openssh does not actually pull in any extra dependencies, it just > adds some optimizations to the network code to make it faster. > Yeah, that. OpenSSH is probably the most security-critical package on our systems. OpenSSH is maintained upstream by a talented team of security-conscious people. The HPN patch is, a) a third-party patch... b) that has been rejected by the talented security-conscious team... c) and is useless for most people. So why are we deciding for our users that they must have it?
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 10:30 AM, Ian Stakenvicius wrote: > > ok you lost me. Could you provide an explicit example of what you > would want to see enabled in the profile (while everything else is > disabled) that you don't get when USE="-*" is set? USE="hardened pax_kernel ..." > > It's sounding more and more like you just want to be able to turn off > all IUSE defaults, and you can effectively do that by changing the USE > order can't you? I don't want to turn off all IUSE defaults. Since we have no policy on what IUSE defaults should be used for, half of them are important, and the other half are junk. I don't want to disable the ones that are critical for the package to function, and I don't want to disable the ones that satisfy an (otherwise unsatisfied) REQUIRED_USE constraint.
Re: [gentoo-dev] Re: Requirements for UID/GID management
On 02/03/2017 09:51 AM, Martin Vaeth wrote: > Michael Orlitzkywrote: >> >> The fact that all permission and ownership information is shared is >> precisely the problem. When you change ownership of the hardlink (which >> you'll never know is a hardlink), you change ownership of /etc/shadow. > > Why should this be a problem except for a race between reading > and changing the ownership? > Admittedly, by using "find ... -exec ... +" the time for an exploit > of the race is even increased when a "standard" chown command is used. > > However, it is no rocket science to write a race-free chown command > in C: Just open the file and use stat() and fchown() to be sure to > change only files from the "correct" user. > > Since this works on the filehandle and not on the filename, I think > that there is no possibility for an exploit when this is used in the > above find loop. Not a bad idea... we chould ship that safe-chown utility, and then tell users how to use it to fix their UIDs. The draft that I wrote up was for the "fixed UID with random fallback" model, but said utility could still be useful for people who want to change their running systems to use the same UIDs that would have been chosen by default.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 12:39 PM, james wrote: So imagine flags are a giant 'sparse matrix' that I need to 'mollify' individually periodically, then run CI on that complete-set of packages, and then test against automated attack vectors. So, were we to want to 'enhance' flag representation from a binary tree form to a sparse matrix, there are many more robust things we can do. For those not aware of sparse matrix benefits, they basically provide for streamlined solving of large complex problems, buy using special (matrix tricks) mathematical techniques to reduce the full, valid set of parameters, into very small sets of smaller problems. IMO, very applicable to CI and flag set testing. These sorts of theories are trivial to test on minimized systems (huge shout out to Walt, as the king of the minimizers!). For starters, I suggest the package listing (i.e.) the future complete listing of gentoo packages down the 'Y' (left) axis and the actual flag status along the (top) X axis. Left Margin and Top margin representations allow the (sub)matrix to be manually viewed as a typical 2-D table, very convenient. First we can alphabetize this 2-D flag matrix for a baseline (base profile) reference matrix. But, once you start thinking about it, recalling your grammar school matrix algebra class, you realized that grouping flags by their myriad of heuristical properties, you realize that the aggregate effect of a flag is not binary at all, but more akin to a 'fuzzy logic' function. For example, cluster up a group of packagers inside the sparse matrix that all have the same flag, but it has different meanings, slightly per package. Turn that flag (on) for all packages and it has a "staccato" effect on the system as a whole. Turn that flag off and it is null-effect (at least theoretically). This is how we currently discern flag setting meanings, but by manually bumbling around in the dark. Now, any number of flag activation, per package of that flag may or may not have secondary (tertiary etc; kinda line harmonics on a LaPlace or Z/s transform) effects on the system as a whole. WE as a community, have been ad-hoc tweaking flags and noting the effects, in an inconsistent manner, with only anecdotal means to share the result of those intrinsic flag settings. Alchemy 2,000 years ago was almost identical to how we (today) analyze flag effects. Grouping all the packages with a given flag, for CI studies allow for row reduction in the sparse matrix of flags, as CI runs are amassed into a larger collective of heuristical interpretations of such specific flag groupings. Or that is my latest treaty_proposal, on how to filter a particular collection of flag settings and installed packages. I am open to other ideas too, as well as traditional regression testing in a hybrid model. Ultimate flexibility in the profile/flag tree, greatly simplifies the automation of CI testing and automated results interpretations, imo. So hopefully I have sufficiently explained my pathway forward, what I need, and how these seemingly disparate issues, are all really just moving parts of a much larger (system) need. At the very least a 100% flexible flag settings/negation, via a profile tree and other mechanisms, will not hinder the formation of matrix representations of flag configuration sets, which are keenly needed to draw reasonable automated conclusions from CI, at least related to flag settings and secondary (inter-intra) flag setting interactions. hth, James
Re: [gentoo-dev] Guidelines for IUSE defaults
On Fri, 3 Feb 2017 08:43:50 -0500 Michael Orlitzkywrote: > On 02/03/2017 08:21 AM, Ian Stakenvicius wrote: > >> > >> How about rather changing our defaults to satisfy the minimalists > >> who don't mind drastically reduced functionality and usability in > >> pursuit of "minimalism" we just strive to make USE="-*" mostly > >> usable, so the minimalists can get what they want, while still > >> having sane defaults. > > > > I'm in favour of this too -- I know we don't "officially" support > > USE="-*" but I think we should still strive to make it work with > > minimal effort to end-users -- that effort being mainly setting > > whatever is necessary for REQUIRED_USE resolution. > > > > It will never be easy, because USE="-*" overrides your profile. What > people want is a way to have USE="-*" apply between the base profile > and the one that they select. > > This is all easily fixed by creating a new profile one-level above > base where developers can put their favorite USE flags: > > 1. We create a new empty profile called "penultimate" inheriting > from base. > > 2. Update the profiles that inherit from base to inherit from > penultimate. > > 3. Move every upstream and maintainer-pet IUSE default into the > penultimate profile. > > 4. Make it policy that IUSE defaults should only be used for > critical flags and REQUIRED_USE persuasion. > > 5. Now we can create embedded, hardened, etc. profiles that inherit > from base and get a minimal working set of USE flags. > We might as well go back to before IUSE defaults then. Part of the advantage of IUSE defaults is maintainers don't all have to fiddle with the profiles, everything can be self-contained in the ebuild. This drastically complicates maintenance, having two locations to track and change rather than just one. I don't know that I would agree that making an absolutely "minimal" build as easy as possible is something that most people want (especially if it makes maintainership more complicated for a significant number of packages). I suspect that there is a small subset of people interested in this, and perhaps those people could maintain a "minimal" profile that unsets IUSE defaults. Also, I would just point out that the particular IUSE default that you objected to in your original email does not really affect this "minimalist" ideal that you seem to hold. The "hpn" USE flag on openssh does not actually pull in any extra dependencies, it just adds some optimizations to the network code to make it faster.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 01:12 AM, Walter Dnes wrote: On Thu, Feb 02, 2017 at 01:01:52PM -0500, Rich Freeman wrote Is there a better way we can have our cake and eat it too? I'll admit that a huge package.use on the minimal profile isn't a whole lot better than a huge package.use on all the other profiles. Do we need another form of syntax in individual ebuilds to try to separate out the various cases you cite? Does anybody care to actually suggest one? I still think that we shouldn't encourage users to lightly deviate from all the upstream defaults. There are of course legitimate reasons for doing so, and you and I can probably appreciate when we should do this, but for somebody starting out we're giving them a lot of rope to hang themselves with. The "case" for IUSE often depends on a fallacious strawman argument about USE="-*". The strawman argument is that people run with the USE variable in make.conf consisting of "USE=-*" and that every package requires an entry in package.use WRONG! WRONG! WRONG! That is a braindead approach. The way I recommend doing it is... USE="-* fu bar blah blah blah" ...where commonly-used flags are included in USE. My rule-of-thumb is Given that * not including a flag in USE requires X entries adding it in package.use * including a flag in USE requires Y entries negating it in package.use If ( X > Y ) then include the the flag in USE else do not include the the flag in USE end if I effectively "build my own profile" rather than depend on multiple levels of inheritance. My current desktop runs with the following USE flags... USE="X apng bindist ffmpeg jpeg opengl png szip truetype x264 x265 xorg threads webp -acl -berkdb -caps -cracklib -crypt -filecaps -gallium -gdbm -graphite -gstreamer -iconv -introspection -ipc -iptables -ipv6 -libav -llvm -manpager -nls -openmp -pam -pch -sendmail -tcpd -udev -unicode -xinerama" Note all the negative flags. I'll try installing uclibc to a laptop one of these days. I figure that it'll probably have a shorter USE line if I start USE with "-*", and I will not have a larger package.use file. +1 I've used Gentoo since 2004. I started down the minimal flag path, first building iptables-based firewalls on gentoo. So that would be a (minimal)base+iptables profile. My historical experience is that flag negation has been a "dirty function" over the years; i.e. not consistent sometimes, across time. That has resulted in a variety of flag negation strategies to "tweek" the final results, seemingly more of an art form with hidden tricks, and a robust (documented) semantic. Most hard to track down problems were in the actual packages (ebuild) as we have danced across EAPI standards all the way back to no EAPI standards and a weak complement of documentation. This happened because of 'package creep' or just needing/wanting to add more and more codes to the firewalls. So now, my firewalls range from truly minimal, all the way to enhancements that supercede suricata. So imagine flags are a giant 'sparse matrix' that I need to 'mollify' individually periodically, then run CI on that complete-set of packages, and then test against automated attack vectors. With CI, in a stage-4 install, we minimalist could test the our collective of (minimized flag) packages and do our own CI. Even perhaps sharing the result of our CI testing of such minimized systems when a gentoo mechanism is available that can handle such massive amounts of data. I proposed this (CI-stage-4) a while back in a gentoo-dev thread and so here we are, again. Granted, this in-house gentoo-CI work was not ready for such wider usage, when I last looked, but it will go a long way in providing a robust tool for minimalist. Many are getting into the minimalist systems, for security reasons too. My needs, on the surface, may(maynot) appear to diverge from Walts, but I surely hope that whatever the consensus solution is, at least for now, it is flexible enough to coalesce all of the various minimalist into the same area of the profile tree. We can then share ideas and results of testing. I really need to apologize to many devs. But, I'm getting very close to having something absolutely wonderful, about 90% thanks to the gentoo devs. I do not want to appear to be childish throwing a tantrum about this, but, well, I just really cannot help it; as y'all can imagine? hth, James
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
2017-02-03 10:52 GMT+01:00 Lars Wendler: > On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote: > > >On 02/03/2017 10:10 AM, Benda Xu wrote: > >> William Hubbs writes: > >> > >>> I have been looking at the meson build system [1] [2], and I like > >>> what I see. > >>> > >>> I have opened an issue on OpenRC's github wrt migrating OpenRC to > >>> the meson build system [3]. > >>> > >>> As I said on the bug, the downside is the addition of py3 and ninja > >>> as build time dependencies, but I think the upside (a build system > >>> where we don't have to worry about parallel make issues or > >>> portability) outweighs that. > >>> > >>> What do folks think here? > >> > >> I would discourage it. Making OpenRC build-depend on python > >> introduces unnecessary complexity that will undermine the > >> portability of OpenRC sooner or later. > >> > >> After all OpenRC is a small program easy to build with a hand-written > >> Makefile. > >> > >> Parallel make issues? No problem let's just solve it. > >> > >> > >> Please, keep it simple. > > > >I'm adding my support to this sentiment > > > > > > +1 > > -- > Lars Wendler > Gentoo package maintainer > GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 > > Attention! New gpg key! See > https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html > Replay @ random using gmail webmail interface; May be worth mentioning that also other distro like Alpine Linux uses openrc, they can be interested
Re: [gentoo-dev] Guidelines for IUSE defaults
On 03/02/17 08:43 AM, Michael Orlitzky wrote: > On 02/03/2017 08:21 AM, Ian Stakenvicius wrote: >>> >>> How about rather changing our defaults to satisfy the minimalists who >>> don't mind drastically reduced functionality and usability in pursuit >>> of "minimalism" we just strive to make USE="-*" mostly usable, so the >>> minimalists can get what they want, while still having sane defaults. >>> >> >> I'm in favour of this too -- I know we don't "officially" support >> USE="-*" but I think we should still strive to make it work with >> minimal effort to end-users -- that effort being mainly setting >> whatever is necessary for REQUIRED_USE resolution. >> > > It will never be easy, because USE="-*" overrides your profile. What > people want is a way to have USE="-*" apply between the base profile and > the one that they select. > ok you lost me. Could you provide an explicit example of what you would want to see enabled in the profile (while everything else is disabled) that you don't get when USE="-*" is set? It's sounding more and more like you just want to be able to turn off all IUSE defaults, and you can effectively do that by changing the USE order can't you? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Requirements for UID/GID management
Michael Orlitzkywrote: > > The fact that all permission and ownership information is shared is > precisely the problem. When you change ownership of the hardlink (which > you'll never know is a hardlink), you change ownership of /etc/shadow. Why should this be a problem except for a race between reading and changing the ownership? Admittedly, by using "find ... -exec ... +" the time for an exploit of the race is even increased when a "standard" chown command is used. However, it is no rocket science to write a race-free chown command in C: Just open the file and use stat() and fchown() to be sure to change only files from the "correct" user. Since this works on the filehandle and not on the filename, I think that there is no possibility for an exploit when this is used in the above find loop.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 08:21 AM, Ian Stakenvicius wrote: >> >> How about rather changing our defaults to satisfy the minimalists who >> don't mind drastically reduced functionality and usability in pursuit >> of "minimalism" we just strive to make USE="-*" mostly usable, so the >> minimalists can get what they want, while still having sane defaults. >> > > I'm in favour of this too -- I know we don't "officially" support > USE="-*" but I think we should still strive to make it work with > minimal effort to end-users -- that effort being mainly setting > whatever is necessary for REQUIRED_USE resolution. > It will never be easy, because USE="-*" overrides your profile. What people want is a way to have USE="-*" apply between the base profile and the one that they select. This is all easily fixed by creating a new profile one-level above base where developers can put their favorite USE flags: 1. We create a new empty profile called "penultimate" inheriting from base. 2. Update the profiles that inherit from base to inherit from penultimate. 3. Move every upstream and maintainer-pet IUSE default into the penultimate profile. 4. Make it policy that IUSE defaults should only be used for critical flags and REQUIRED_USE persuasion. 5. Now we can create embedded, hardened, etc. profiles that inherit from base and get a minimal working set of USE flags.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/17 10:14 PM, Patrick McLean wrote: > On Thu, 2 Feb 2017 20:40:38 -0500 > Michael Orlitzkywrote: > >> On 02/02/2017 01:01 PM, Rich Freeman wrote: >>> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky >>> wrote: If (base == minimal), then all of the upstream defaults need to be added to package.use for the upstream-defaults profile. That's bad, >>> >>> I'll go further and say that it is unacceptably bad. >>> >> >> Only if anyone wants an upstream-defaults profile. But nobody's asked >> for one, in contrast with the large number of users who want minimal. >> >> >>> Is there a better way we can have our cake and eat it too? I'll >>> admit that a huge package.use on the minimal profile isn't a whole >>> lot better than a huge package.use on all the other profiles. >> >> Every important upstream default is already enabled in some profile. >> If dropping a particular IUSE default breaks desktop systems, then >> that flag belongs enabled in the desktop profile. If it breaks every >> system, then let's keep it default. >> > > How about rather changing our defaults to satisfy the minimalists who > don't mind drastically reduced functionality and usability in pursuit > of "minimalism" we just strive to make USE="-*" mostly usable, so the > minimalists can get what they want, while still having sane defaults. > I'm in favour of this too -- I know we don't "officially" support USE="-*" but I think we should still strive to make it work with minimal effort to end-users -- that effort being mainly setting whatever is necessary for REQUIRED_USE resolution. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/17 08:21 PM, Michael Orlitzky wrote: > On 02/02/2017 06:41 PM, Ian Stakenvicius wrote: >> Responding here instead of the first time it was posted, just 'cause. >> >> On 02/02/17 06:35 PM, james wrote: >>> " >>> I'm not saying that we should have a minimal experience out-of-the-box, >>> only that the base profile should result in an effectively-minimal set >>> of USE flags. Adding IUSE defaults is essentially adding defaults to the >>> base profile." >> >> Yes. More specifically, it's adding these defaults without setting >> the flags globally, thereby not introducing system-wide defaults >> across all packages but only those that make sense on a per-package >> basis for that package to operate properly. >> >> IMO this is the effectively minimal-set of use flags we should have. > > I... agree? We should enable the flags that are necessary for the > package to work, and we should enable whatever is necessary to avoid > REQUIRED_USE roadblocks. That's what I started out by suggesting. > Where we disagree is that this includes all of scenarios #2, #3, and #4 IMO. #4 perhaps less so than the others, but IMO if there is a good reason feature-wise for that to be default-enabled, then the maintainer should still default-enable it and do so via IUSE-defaults. Remember one of the primary reasons IUSE-defaults came about is because maintainers were doing all of these things, but using "no*" flags so that the features would be default-enabled. I don't think any of us want to see that again. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Gentoo Dinner@FOSDEM 2017
Hi, Here are the practifcal informations for the Gentoo Dinner. Place: Chez Léon, rue des Bouchers 18, 1000 Brussels (near the Grand Place) [2] Date: Sat 4 Feb, 20:15 Menu: 30,60 EUR 28 places are ordered, based on the wiki page list [1]. See you tomorrow, Xavier. Le 2017-01-24 20:28, Xavier Miller a écrit : Hi! The traditional Gentoo Dinner @ FOSDEM 2017 comes back! If you are interested, please edit the Wiki page[1]. I see some "possible" or "maybe", can you please confirm to "yes" or "no" as soon as possible? Kind regards, Xavier Miller [1] https://wiki.gentoo.org/wiki/FOSDEM_2017 [2] http://www.chezleon.be/en/general-information/
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote: >On 02/03/2017 10:10 AM, Benda Xu wrote: >> William Hubbswrites: >> >>> I have been looking at the meson build system [1] [2], and I like >>> what I see. >>> >>> I have opened an issue on OpenRC's github wrt migrating OpenRC to >>> the meson build system [3]. >>> >>> As I said on the bug, the downside is the addition of py3 and ninja >>> as build time dependencies, but I think the upside (a build system >>> where we don't have to worry about parallel make issues or >>> portability) outweighs that. >>> >>> What do folks think here? >> >> I would discourage it. Making OpenRC build-depend on python >> introduces unnecessary complexity that will undermine the >> portability of OpenRC sooner or later. >> >> After all OpenRC is a small program easy to build with a hand-written >> Makefile. >> >> Parallel make issues? No problem let's just solve it. >> >> >> Please, keep it simple. > >I'm adding my support to this sentiment > > +1 -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpEkZOYA01EV.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On 02/03/2017 10:10 AM, Benda Xu wrote: > William Hubbswrites: > >> I have been looking at the meson build system [1] [2], and I like what I >> see. >> >> I have opened an issue on OpenRC's github wrt migrating OpenRC to the >> meson build system [3]. >> >> As I said on the bug, the downside is the addition of py3 and ninja as >> build time dependencies, but I think the upside (a build system where >> we don't have to worry about parallel make issues or portability) >> outweighs that. >> >> What do folks think here? > > I would discourage it. Making OpenRC build-depend on python introduces > unnecessary complexity that will undermine the portability of OpenRC > sooner or later. > > After all OpenRC is a small program easy to build with a hand-written > Makefile. > > Parallel make issues? No problem let's just solve it. > > > Please, keep it simple. I'm adding my support to this sentiment -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
William Hubbswrites: > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? I would discourage it. Making OpenRC build-depend on python introduces unnecessary complexity that will undermine the portability of OpenRC sooner or later. After all OpenRC is a small program easy to build with a hand-written Makefile. Parallel make issues? No problem let's just solve it. Please, keep it simple. Benda signature.asc Description: PGP signature
[gentoo-dev] Re: Guidelines for IUSE defaults
Michael Orlitzky posted on Thu, 02 Feb 2017 10:49:41 -0500 as excerpted: > On 02/02/2017 09:56 AM, Ian Stakenvicius wrote: >> >>> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky>>> wrote: >>> >>> IUSE defaults are used in a few different ways: >>> >>> 1 To ensure that critical functionality is enabled. >>> >>> * Example: force the "unix" module for apache. >>> >>> >> This is not what IUSE defaults are for, this should be done with >> package.use{,.stable}.{mask,force} in profiles. If functionality is >> critical then there (A) shouldn't be a use flag, or (B) shouldn't be a >> way for USE= in make.conf to disable it. >> >> > If we adopted this policy, then USE="-*" would no longer be guaranteed > to break the system. It does still ignore your profile defaults, though, > which presumably are important (e.g. for hardened). So we're still left > with no way for me to turn off everyone's pet USE flags and keep my > system working. If USE="-*" is a guarantee of a broken system, it's a pretty weak one. In fact, so is flying with an empty @system (everything in the profile negated), as I do both of the above. And in fact, my gentoo-based-admin life has been far simpler since I set it up that way. =:^) The biggest benefit of USE="-*" is that I no longer have to worry about investigating the "why" of USE flag changes when I change to a different profile, or when devs change my existing profile out from under me. I have a set of USE flags I've decided I want (or need for long-term- installed stuff like kde), and all packages that don't work with that default -- for instance, packages that required-use qt4 XOR qt5, already have their package.use setup as appropriate. Otherwise, when I upgrade to a new profile, as I've needed to do several times over the nearing a decade and a half I've been running the same original installation rolling-update gentoo on rolling-update hardware, I have to do a bunch of research on all the USE flags that changed and how they affect my existing installation due to --newuse. This way, that was all managed at the time I encountered the original USE flag conflict, and the profile I choose doesn't mess with my USE flags at all except via forces (which I can override if I have to, but I haven't had to, a testament to the wisely conservative usage of forced-USE). Of course, I can and do still use the USE flags set in a profile as a guide, and that was a tremendous help in the kde-apps5/frameworks5/plasma5 upgrade process despite the fact that I couldn't actually use the profile designed for that. The biggest weakness, meanwhile, is that with USE="-*" there's no easy way to actually see what a package's USE-defaults are, without actually opening up the ebuild (or at least grepping) to see. I've often wished there was some way to denote the default-on flags in emerge --pretend/-- ask so I could see what they are on a new package, and investigate why if necessary, but I understand the problem of a limited available symbol- space, and actually looking in the ebuild isn't /horribly/ hard... as long as there's multiple terminals available to do it in, without unnecessarily canceling the --ask output that took so long to appear. Of course it would be a bit different if I could actually use a profile with all the bits I needed, nomultilib, systemd, plasma, amd64, primarily. But until mixins, nomultilib generally means at least some of the other stuff isn't available in a profile, so I gotta simply pick the nomultilib profile that best matches and check the other profiles, for example plasma, using them as a guide to set my flags the way I need them. Similarly with @system. Negating the entire thing a package at a time and seeing what --depclean wants to clean, then adding as appropriate to a set listed in world_sets if it's /really/ needed, means I don't have to worry about package.providing openrc, for instance, because it's not necessary with systemd, once a single symlink is setup. Similarly with ssh if it's only a stand-alone system you're admining. And most of the @system virtuals can simply be dropped, as specific selections from those virtuals have already been added to some set listed in world_sets. Of course it helps that my routine-use emerge aliases have --ask --verbose --oneshot. (I don't configure those as emerge-defaults because I do for example want --pretend occasionally instead of --ask.) But that's a lesson most gentooers should have learned within six months. Anyway, USE="-*" hardly breaks the system here. In fact, rather the opposite, it fixes what was previously a major headache of a workaround for a broken system every time my profile changed, because I was setting most USE flags I wanted but until then, not *ALL* of them, in part because I couldn't see what I had missed because the profile was setting it for me... until it didn't, thus creating the problem. So for some people,