[gentoo-dev] Re: Implicit system dependency
On 05/11/14 12:16, Michael Orlitzky wrote: When I was taking my ebuild quizzes, I asked for someone to clarify the implicit system dependency that we have enshrined in the devmanual: https://bugs.gentoo.org/show_bug.cgi?id=485356 There is... some agreement, but also special cases and special-special cases that are folklore-only at this point. To me it seems like a fine thing to ask the council to sort out, so I'm asking here for discussion. Can we come up with an idiot-proof list (or FLOWCHART, even!) of what should and should not be excluded from *DEPEND? Suggested policy to get the ball rolling: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: * C compiler and runtime * C++ compiler and runtime * A POSIX-compliant shell * bash, baselayout, binutils, coreutils, findutils, grep, make * Any archive tools (eg. tar, bzip2, xz-utils) where used for unpacking SRC_URI only * Any command guaranteed by PMS at build-time only (eg. sed, patch) Note that in some cases it might be necessary to explicitly specify a dependency that's listed above, such as when a specific implementation is required (eg. a binary package requiring glibc).
Re: [gentoo-dev] Unify keyring related USE flags
El dom, 12-10-2014 a las 10:38 +0200, Pacho Ramos escribió: El dom, 12-10-2014 a las 00:13 +0400, Alexander Tsoy escribió: [...] I think we should simply have a keyring USE flag to enable what most people will want - keyring support. Some apps have optional support for both kwallet and gnome-keyring (e.g. darktable, subversion). So I'm not sure you can leave a single USE flag. Maybe for them we could have an exception or review them as they also look to be a bit strange. For example, for concrete case of subversion looks like it's using gnome-keyring and kde, that looks a bit inconsistent to me. We could use gnome and kde for example :/. Or have a keyring USE flag and, then gnome and kde behind that USE any updates on this? :)
Re: [gentoo-dev] Unify keyring related USE flags
В Thu, 13 Nov 2014 11:53:56 +0100 Pacho Ramos pa...@gentoo.org пишет: El dom, 12-10-2014 a las 10:38 +0200, Pacho Ramos escribió: El dom, 12-10-2014 a las 00:13 +0400, Alexander Tsoy escribió: [...] I think we should simply have a keyring USE flag to enable what most people will want - keyring support. Some apps have optional support for both kwallet and gnome-keyring (e.g. darktable, subversion). So I'm not sure you can leave a single USE flag. Maybe for them we could have an exception or review them as they also look to be a bit strange. For example, for concrete case of subversion looks like it's using gnome-keyring and kde, that looks a bit inconsistent to me. We could use gnome and kde for example :/. Or have a keyring USE flag and, then gnome and kde behind that USE any updates on this? :) I don't know anything about kwallet, but gnome-keyring is useful outside of GNOME. So I don't like the idea of hiding gnome-keyring behind gnome use flag. -- Alexander Tsoy
Re: [gentoo-dev] Unify keyring related USE flags
El jue, 13-11-2014 a las 14:12 +0300, Alexander Tsoy escribió: В Thu, 13 Nov 2014 11:53:56 +0100 Pacho Ramos pa...@gentoo.org пишет: El dom, 12-10-2014 a las 10:38 +0200, Pacho Ramos escribió: El dom, 12-10-2014 a las 00:13 +0400, Alexander Tsoy escribió: [...] I think we should simply have a keyring USE flag to enable what most people will want - keyring support. Some apps have optional support for both kwallet and gnome-keyring (e.g. darktable, subversion). So I'm not sure you can leave a single USE flag. Maybe for them we could have an exception or review them as they also look to be a bit strange. For example, for concrete case of subversion looks like it's using gnome-keyring and kde, that looks a bit inconsistent to me. We could use gnome and kde for example :/. Or have a keyring USE flag and, then gnome and kde behind that USE any updates on this? :) I don't know anything about kwallet, but gnome-keyring is useful outside of GNOME. So I don't like the idea of hiding gnome-keyring behind gnome use flag. But people wanting keyring support in gnome will know need to remember to also enable libsecret (that will replace gnome-keyring at some point). That is the main reason for suggesting the change. That and also that kde USE flag is being used for keyring support in KDE environment, and that can look a bit incoherent. Having a more general keyring USE flag people could enable and, for cases with multiple support, allow to switch between providers on KDE and GNOME depending on their kde gnome USE flags looks to solve it for me :/
Re: [gentoo-dev] Re: Implicit system dependency
On 11/13/2014 05:30 AM, Michael Palimaka wrote: Suggested policy to get the ball rolling: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: * C compiler and runtime Specifically sys-devel/gcc and sys-libs/glibc (i.e. what's in @system), or just anything? * C++ compiler and runtime Isn't it possible to disable C++ in GCC with USE=-cxx?
Re: [gentoo-dev] Re: Implicit system dependency
On Thu, Nov 13, 2014 at 5:30 AM, Michael Palimaka kensing...@gentoo.org wrote: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: So, I'm not a big fan of implicit dependencies in general. What does the new policy buy us that the existing one does not? Why not try to find a way to ditch implicit dependencies entirely? If the issue is that nobody wants to have a laundry list of dependencies in every package, why not use something like a virtual to pull in all the commonly-used stuff. Then for the 0.1% of the tree where it matters we could list things explicitly so that we don't have a big pile of packages that portage can't parallelize. It seems like the problems with the current approach are: 1. @system can vary by profile, which allows bugs to creep in since maintainers can't stay on top of what is and isn't always in @system). 2. PMs can't build @system packages in parallel, since it doesn't know what the real deps are. 3. The way we use @system makes it hard to tell if it is safe to remove some package which is otherwise heavily-used. You never really know if you can safely do without bash, and so on. (Note, this bit wouldn't be helped at all by simply turning system into a big virtual.) I'm not entirely sure what problem you're trying to solve, so the above may or may not be helpful. I'm fine with incremental improvements if they actually improve something. Otherwise, the status quo does have the benefit of simplicity - you don't have to list @system packages as dependencies ever, but you can do so if you wish or it brings some benefit (deps on specific versions/slots, slot-operator deps, etc). -- Rich
[gentoo-dev] Re: Implicit system dependency
On Thu, 13 Nov 2014, Michael Palimaka wrote: Suggested policy to get the ball rolling: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: * C compiler and runtime * C++ compiler and runtime * A POSIX-compliant shell * bash, baselayout, binutils, coreutils, findutils, grep, make awk? diffutils? texinfo? * Any archive tools (eg. tar, bzip2, xz-utils) where used for unpacking SRC_URI only * Any command guaranteed by PMS at build-time only (eg. sed, patch) Note that in some cases it might be necessary to explicitly specify a dependency that's listed above, such as when a specific implementation is required (eg. a binary package requiring glibc). Ulrich pgpW3w8N0DplE.pgp Description: PGP signature
[gentoo-dev] Re: Implicit system dependency
On 14/11/14 01:17, Rich Freeman wrote: On Thu, Nov 13, 2014 at 5:30 AM, Michael Palimaka kensing...@gentoo.org wrote: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: So, I'm not a big fan of implicit dependencies in general. What does the new policy buy us that the existing one does not? Why not try to find a way to ditch implicit dependencies entirely? If the issue is that nobody wants to have a laundry list of dependencies in every package, why not use something like a virtual to pull in all the commonly-used stuff. Then for the 0.1% of the tree where it matters we could list things explicitly so that we don't have a big pile of packages that portage can't parallelize. The problem is the current policy is not particularly clear - the issue of when to explicitly specify a system dependency keeps coming up. The first two sentences say all system dependencies are implicit and should not be specified, while contradicted by the third in some (but not all cases). Ditching implicit dependencies is an interesting idea but not practical. Nobody wants to the laundry list, and there's little benefit in maintaining a virtual/system clone of @system. It seems like the problems with the current approach are: 1. @system can vary by profile, which allows bugs to creep in since maintainers can't stay on top of what is and isn't always in @system). 2. PMs can't build @system packages in parallel, since it doesn't know what the real deps are. 3. The way we use @system makes it hard to tell if it is safe to remove some package which is otherwise heavily-used. You never really know if you can safely do without bash, and so on. (Note, this bit wouldn't be helped at all by simply turning system into a big virtual.) I'm not entirely sure what problem you're trying to solve, so the above may or may not be helpful. I'm fine with incremental improvements if they actually improve something. Otherwise, the status quo does have the benefit of simplicity - you don't have to list @system packages as dependencies ever, but you can do so if you wish or it brings some benefit (deps on specific versions/slots, slot-operator deps, etc). This is just about clarifying things. The wording of the current policy is vague (don't depend on system dependencies, but consider sometimes doing it) and I think something more explicit would be better. An update would help better reflect reality too - most people depend on app-arch/bzip2 for libbzip2 even though it's in @system.
Re: [gentoo-dev] Re: Implicit system dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/11/14 09:05 AM, Michael Orlitzky wrote: On 11/13/2014 05:30 AM, Michael Palimaka wrote: Suggested policy to get the ball rolling: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: * C compiler and runtime Specifically sys-devel/gcc and sys-libs/glibc (i.e. what's in @system), or just anything? I would sincerely hope that nothing in the tree explicitly requires gcc as a C compiler. Glibc is a bit different, it may be necessary to explicitly depend on it (or use the elibc_glibc flag) if the package can't work with the libc alternatives, but ideally * C++ compiler and runtime Isn't it possible to disable C++ in GCC with USE=-cxx? It is.. but unfortunately there's no way in DEPEND to ensure it's satisfied, as you can have a gcc installed with that flag enabled but have a second one (that's actually selected in gcc-config) with it disabled. A pkg_pretend check or a pkg_setup check (if you don't want it to just fail in src_configure) is probably the best way to enforce that one at this time. Unless there are other ways I'm not aware of?? There's also the whole c++98 vs c++11 issue that's sort-of part of this -- minimum clang version, minimum gcc version might relate. Again though, afaik there's no easy way to deal with this in DEPEND. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRky4AACgkQ2ugaI38ACPD1twD/da6rptWk1/vl2iDPSBWLmox2 5rXr7aEci8yCBoyDsk8A/0ZAGBtxlBWqoTGKzkJdm32pow4cOtFBEBO+YoVJkEyx =xXHM -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Implicit system dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/11/14 10:17 AM, Ian Stakenvicius wrote: On 13/11/14 09:05 AM, Michael Orlitzky wrote: On 11/13/2014 05:30 AM, Michael Palimaka wrote: Suggested policy to get the ball rolling: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: * C compiler and runtime Specifically sys-devel/gcc and sys-libs/glibc (i.e. what's in @system), or just anything? I would sincerely hope that nothing in the tree explicitly requires gcc as a C compiler. Glibc is a bit different, it may be necessary to explicitly depend on it (or use the elibc_glibc flag) if the package can't work with the libc alternatives, but ideally [...] ... we shouldn't be depending on the specific libc implementation -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRky8wACgkQ2ugaI38ACPBEEwD+JmErQK2aUPcYsZY6e55lWYfO oenrhAK3S4bKX8CdOWoA/1NKBesQnsv6e8KEwPEQrHlQO3DcCA/DVVWPWjUSVCjo =+Web -END PGP SIGNATURE-
[gentoo-dev] Re: Implicit system dependency
On 14/11/14 01:36, Ulrich Mueller wrote: On Thu, 13 Nov 2014, Michael Palimaka wrote: Suggested policy to get the ball rolling: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: * C compiler and runtime * C++ compiler and runtime * A POSIX-compliant shell * bash, baselayout, binutils, coreutils, findutils, grep, make awk? diffutils? texinfo? I have no particular opinion on what should be included (or even if we should have a whitelist - I am mainly interested in capturing library usage). If we do have a whitelist, it would be useful to figure out what in @system is intended to be actually be part of the base system and what is there for convenience (eg. virtual/ssh).
[gentoo-dev] Re: Implicit system dependency
On 14/11/14 01:05, Michael Orlitzky wrote: On 11/13/2014 05:30 AM, Michael Palimaka wrote: Suggested policy to get the ball rolling: In general, a package must explicitly depend upon what it directly uses. However, to avoid ebuild complexity and developer burden there are some exceptions. Packages that appear in the base system set may be omitted from an ebuild's dependency list in the following circumstances: * C compiler and runtime Specifically sys-devel/gcc and sys-libs/glibc (i.e. what's in @system), or just anything? Since they can be (in theory) replaced with some other implementation, anything unless there's a reason (like a binary package explicitly linking to glib). * C++ compiler and runtime Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-)
Re: [gentoo-dev] Re: Implicit system dependency
On 11/13/2014 04:27 PM, Michael Palimaka wrote: * C++ compiler and runtime Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) I keep hearing this sentence, but it still doesn't make much sense to me. Invalid configurations should be reported as invalid to the user. Since I run my own server with USE=-* foo bar I have come across a lot of expect users to not disable it, but don't actually disallow it or even warn them. I've seen a lot of compiler checks in ebuilds in pkg_pretend that look quite similar. Maybe it's time to enhance toolchain-funcs?
Re: [gentoo-dev] Re: Implicit system dependency
On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 01:05, Michael Orlitzky wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) Perhaps we should add a package.use.force entry for this. Is there any reason not to?
Re: [gentoo-dev] Re: Implicit system dependency
Mike Gilbert wrote: On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 01:05, Michael Orlitzky wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) Perhaps we should add a package.use.force entry for this. Is there any reason not to? There are people that don't want c++ and gcc:4.7 can still bootstrap without.
Re: [gentoo-dev] Re: Implicit system dependency
Dnia 2014-11-13, o godz. 13:13:01 Mike Gilbert flop...@gentoo.org napisał(a): On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 01:05, Michael Orlitzky wrote: Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) Perhaps we should add a package.use.force entry for this. Is there any reason not to? You may want to install a minimalistic version of an old gcc for some (non-C++) testing. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Implicit system dependency
On Thu, Nov 13, 2014 at 10:07 AM, Michael Palimaka kensing...@gentoo.org wrote: Ditching implicit dependencies is an interesting idea but not practical. Nobody wants to the laundry list, and there's little benefit in maintaining a virtual/system clone of @system. Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. As far as benefits go, they include: 1. No need to have multiple ways of grouping packages. 2. You can more than one virtual, so that you could just pull in the super-lazy equivalent to @system, or maybe you just pull in POSIX+bash and C++ or something like that. 3. You can split up that virtual so that convenience packages like ssh aren't in the same virtual as widespread dependencies like bash/zlib/glibc/gcc/etc. There is no reason that you can't build openssh in parallel, but right now you can't because we lump it in with glibc. 4. You can choose when to use the virtual at all, versus explicitly naming all dependencies. For 99% of packages it would be the same. We could even have that dependency added automatically if something isn't done in the ebuild to disable it, which would make ebuilds work the same as they do now. However, for the packages that are actually in @system we could list explicit dependencies and then portage would actually be able to handle some things automatically. Also, by using virtuals that are the same across all archs, we have a bit more consistency. Policy-wise, though, the status quo isn't that bad. You never have to list dependencies that are in @system, full stop. You can list a dependency that is in @system anytime you want to, full stop. That is, it is never right or wrong to list an unversioned dependency that is in @system. Sometimes doing one or the other is advantageous (such as when you have a versioned dependency, or a virtual is in @system but you need a specific implementation, or you want to use a slot-op dep). I'm fine with examples, but they shouldn't be firm rules, just helpful guidelines. -- Rich
[gentoo-dev] Re: Implicit system dependency
On 14/11/14 03:57, hasufell wrote: On 11/13/2014 04:27 PM, Michael Palimaka wrote: * C++ compiler and runtime Isn't it possible to disable C++ in GCC with USE=-cxx? It is, but I think if that's disabled you're on your own. :-) I keep hearing this sentence, but it still doesn't make much sense to me. Invalid configurations should be reported as invalid to the user. Since I run my own server with USE=-* foo bar I have come across a lot of expect users to not disable it, but don't actually disallow it or even warn them. I've seen a lot of compiler checks in ebuilds in pkg_pretend that look quite similar. Maybe it's time to enhance toolchain-funcs? It definitely would be nice to have some better mechanism for compiler checking in general. Already version checking is quite ugly with boilerplate code everywhere with wrong dependencies like =gcc-4.7.
[gentoo-dev] Re: Implicit system dependency
On 14/11/14 11:06, Rich Freeman wrote: On Thu, Nov 13, 2014 at 10:07 AM, Michael Palimaka kensing...@gentoo.org wrote: Ditching implicit dependencies is an interesting idea but not practical. Nobody wants to the laundry list, and there's little benefit in maintaining a virtual/system clone of @system. Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. Will that work? Some profiles remove packages from the base @system and replace it with their own implementations (eg. BSD). As far as benefits go, they include: 1. No need to have multiple ways of grouping packages. 2. You can more than one virtual, so that you could just pull in the super-lazy equivalent to @system, or maybe you just pull in POSIX+bash and C++ or something like that. 3. You can split up that virtual so that convenience packages like ssh aren't in the same virtual as widespread dependencies like bash/zlib/glibc/gcc/etc. There is no reason that you can't build openssh in parallel, but right now you can't because we lump it in with glibc. 4. You can choose when to use the virtual at all, versus explicitly naming all dependencies. For 99% of packages it would be the same. We could even have that dependency added automatically if something isn't done in the ebuild to disable it, which would make ebuilds work the same as they do now. However, for the packages that are actually in @system we could list explicit dependencies and then portage would actually be able to handle some things automatically. Also, by using virtuals that are the same across all archs, we have a bit more consistency. Definitely interesting ideas, but I think it's beyond the scope of what's trying to be addressed here. Solving bug #393445 would also go a long way to sorting out core-system vs. want-to-have packages. Policy-wise, though, the status quo isn't that bad. You never have to list dependencies that are in @system, full stop. You can list a dependency that is in @system anytime you want to, full stop. That is, it is never right or wrong to list an unversioned dependency that is in @system. Sometimes doing one or the other is advantageous (such as when you have a versioned dependency, or a virtual is in @system but you need a specific implementation, or you want to use a slot-op dep). I'm fine with examples, but they shouldn't be firm rules, just helpful guidelines. Maybe some dependencies (within reason) should always be listed, for example when there's linkage eg. to libbzip2 or liblzma. That would make it easy to find consumers eg. if an alternate implementation appeared, and already appears to be a common practice. Perhaps instead of creating a whitelist, we could just update the text a bit: All packages have an implicit compile-time and runtime dependency upon the entire system target. For toolchain packages part of the system target (such as gcc, libc, binutils and so on) it is not necessary, nor advisable, to specify dependencies, except where specific versions or packages (for example, glibc over uclibc) are required. For other non-toolchain packages part of the system target (such as bzip2 or wget) it is optional to specify a dependency. Consideration should be given to packages that don't appear in system targets in other profiles or might be removed in the future. Where package links to package in the system target (such as libbz2) it is recommended to specify a dependency.
Re: [gentoo-dev] Java7 stabilization
On Mon, 10 Nov 2014 12:23:43 +0100 Pacho Ramos pa...@gentoo.org wrote: Hello Hello, this is an individual response. I would like to see if we could finally try to stabilize java7 on Gentoo as some external tools start to require it. There is currently this tracker opened: https://bugs.gentoo.org/show_bug.cgi?id=384609 I am unsure why: https://bugs.gentoo.org/show_bug.cgi?id=483018 should block the stabilization as we can have multiple java versions installed due slots Multiple stable Java versions means more work; so, you'll instead want to bring incompatible packages forward to Java 7 or mask and lastrite them as time goes by. The tracker list two broken packages that would need either patching or to be forced to use older slots and this one: Under the work train of thoughts, an older slot is a temporary measure. https://bugs.gentoo.org/show_bug.cgi?id=515830 That looks more important. Then, I also wonder about what implementations are we meant to look for this stabilization. Should we look for bugs affecting icedtea-bin and also oracle's implementation? If you look at the history, multiple implementations are stabilized; this means that bugs should indeed look at whether they affect both versions. In general, fixing a bug for one implementation fixes it for the other implementation or the other implement didn't even have the bug to begin with; but that shouldn't fool us to check them both out. (I was wondering if the tracker was really collecting all the issues :/) Doubtful. A tree wide check is necessary to confirm that all Java based packages build with the to be stabilized Java 7 implementations.
Re: [gentoo-dev] Packages up for grabs
On Tue, 11 Nov 2014 16:59:46 +0200 Pavlos Ratis daster...@gentoo.org wrote: I will also drop myself from the net-proxy herd. Drawing extra attention to this sentence; it looks like the herd is (once again) going to be empty, as the result of a lack of interest. If someone does have a real interest in this herd; please step up now, otherwise this herd is probably going to face a removal in the future.
[gentoo-dev] Packages up for grabs
Hello all Due to lack of time I'm giving up some packages. Feel free to take them: app-admin/ec2-ami-tools app-admin/ec2-api-tools These command-line tools serve as the client interface to the Amazon EC2 web service app-admin/logmon Split-screen terminal/ncurses based log viewer app-admin/usermin A web-based user administration interface app-admin/yaala Yet Another Log Analyzer app-editors/retext A Qt-based text editor for Markdown and reStructuredText app-misc/fslint A utility to find various forms of lint on a filesystem app-text/logmerge Merge multiple logs such that multilined entries appear in chronological order without breaks dev-games/aseprite Animated sprite editor and pixel art tool dev-python/markups A wrapper around various text markups dev-util/cdiff Colored, side-by-side diff terminal viewer dev-util/oprofile A transparent low-overhead system-wide profiler media-libs/libmkv Lightweight Matroska muxer written for HandBrake media-sound/teamspeak-client-bin media-sound/teamspeak-server-bin TeamSpeak Client / Server (Voice Communication Software) media-video/openshot Free, open-source, non-linear video editor to create and edit videos and movies sys-apps/epoch An init system (analogous to systemd or upstart) for Linux by Subsentient; it is intended as a lightweight solution for lightweight distributions that don't want a huge mess just to boot up; it has one unified configuration file, is very small in size, and it has no external dependencies besides glibc or similar; installing a shell for /bin/sh is strongly recommended sys-process/ftop Monitor open files and filesystems www-misc/monitorix A lightweight system monitoring tool x11-misc/growl-for-linux A Linux-compatible version of Growl, a notification system for Mac OS X Thanks, Tom Wijsman
Re: [gentoo-dev] Re: Implicit system dependency
On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 11:06, Rich Freeman wrote: Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. Will that work? Some profiles remove packages from the base @system and replace it with their own implementations (eg. BSD). Maybe. The thing is that a package either depends on something or it doesn't. If it really does depend on something, then the fact that it isn't available on BSD/etc isn't going to magically make the package work. We just loosely define system dependencies in a way that makes them work 98% of the time, basically accepting that things are going to break and we get away with it because few of our users actually run on BSD/etc. If it is just a matter of preference then a profile could install an alternative package that is in a virtual. However, this won't work if everybody still uses some convenience virtual that pulls in bash/etc and the BSD folks don't want to install bash unnecessarily. The only perfect solution is explicit dependencies across the board. If we want to be lazy and not have to list 50 deps for hello world, then the package manager isn't going to know whether hello world actually works on every arch/profile/etc. Maybe the better solution is some kind of automation around (R)DEPEND. In any case, I agree that it is a bit beyond the original scope of this. Maybe some dependencies (within reason) should always be listed, for example when there's linkage eg. to libbzip2 or liblzma. That would make it easy to find consumers eg. if an alternate implementation appeared, and already appears to be a common practice. The problem is that if it isn't 100% then it isn't all that great a solution. It also isn't really necessary unless you want to remove a package from the system set. If an alternative implementation appears, then you create a virtual, place that virtual in the system set, and all the packages in the tree remain happy to use whatever implementation the user has installed without the risk of it getting depcleaned. In the past when we've considered removing a package from @system there is usually a thread on -dev, and if there is a general sense that we want to move forward then the announcement goes out for everybody to check their packages and add an explicit dependency if needed (often with tinderbox runs and the like). Then after a delay the package is removed from @system and maintainers get to deal with anything they missed. I don't have a problem with devs listing dependencies anytime they're real and they feel it makes sense to do so. I wouldn't make a push to have them go out of their way to do it for any particular package unless we are actively looking to remove it from @system, or there is some other driver. Slot operator deps would be the one case where I would try to push on maintainers to list deps. And I do apologize for piling on a bit - trying to get rid of @system has been one of my soap box issues for a while. It really seems like an ugly, if practical, solution. -- Rich
Re: [gentoo-dev] Re: Implicit system dependency
On 11/13/2014 08:01 PM, Rich Freeman wrote: On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka kensing...@gentoo.org wrote: On 14/11/14 11:06, Rich Freeman wrote: Well, the idea would be to maintain the virtual INSTEAD of @system, or have @system just pull in the virtual and make some arch-specific additions. Will that work? Some profiles remove packages from the base @system and replace it with their own implementations (eg. BSD). Maybe. The thing is that a package either depends on something or it doesn't. If it really does depend on something, then the fact that it isn't available on BSD/etc isn't going to magically make the package work. We just loosely define system dependencies in a way that makes them work 98% of the time, basically accepting that things are going to break and we get away with it because few of our users actually run on BSD/etc. If it is just a matter of preference then a profile could install an alternative package that is in a virtual. However, this won't work if everybody still uses some convenience virtual that pulls in bash/etc and the BSD folks don't want to install bash unnecessarily. Maybe I'm missing something, but if you are using virtuals, then you can make the deps conditional on profile forced/masked flags like userland_BSD and userland_GNU if necessary. These behave like normal USE flags, aside from the fact the they are forced or masked by profiles. -- Thanks, Zac
Re: [gentoo-portage-dev] [PATCH] FEATURES=case-insensitive-fs for bug #524236
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/11/14 02:22, Zac Medico wrote: +if case-insensitive-fs in portage.settings.features: +FIND_EXTANT_CONFIGS = \ +FIND_EXTANT_CONFIGS.replace(-name '._cfg, -iname '._cfg) + Splitting inside the replace will look nicer following PEP indentation (as you won't need the '\'). +Use case\-insensitive file name comparisions when merging and unmerging +files. +.TP Maybe mention a) that most people can ignore this option, and b) who it's actually for. Kind of in the kernel option help style. In general I don't like this patch. It handles a bunch of cases separately by doing lower(), when I think instead it should be handled implicitly. The data should be in a structure such that it knows whether it is supposed to be upper or lowercase, and whatever's dealing with it should deal with it accordingly, rather than checking is this case insensitive? OK lowercase it before sending it wherever. But if you think this is the best way, I'm not going to stand in the way of this patch. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlRkiB0ACgkQRtClrXBQc7UudAD/V1r4AR5zA54Xz+LHBVNt0bnn uQ9w+146L8WYK6pDN9gBAJxZbQREeOwxKSDjluZ1lq9XARf1rh/Eqzl58wIc8I4K =c1Em -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] FEATURES=case-insensitive-fs for bug #524236
On 11/13/2014 02:29 AM, Alexander Berntsen wrote: On 13/11/14 02:22, Zac Medico wrote: +if case-insensitive-fs in portage.settings.features: +FIND_EXTANT_CONFIGS = \ +FIND_EXTANT_CONFIGS.replace(-name '._cfg, -iname '._cfg) + Splitting inside the replace will look nicer following PEP indentation (as you won't need the '\'). Okay, I'll re-format it as you've suggested. +Use case\-insensitive file name comparisions when merging and unmerging +files. +.TP Maybe mention a) that most people can ignore this option, and b) who it's actually for. Kind of in the kernel option help style. Okay, I'll add something about it only being needed for case-insensitive file systems, which are usually not used. In general I don't like this patch. It handles a bunch of cases separately by doing lower(), when I think instead it should be handled implicitly. The data should be in a structure such that it knows whether it is supposed to be upper or lowercase, and whatever's dealing with it should deal with it accordingly, rather than checking is this case insensitive? OK lowercase it before sending it wherever. Aside from the ConfigProtect constructor, which has a new case_insensitive keyword parameter, all affected methods handle case transformations implicitly, as far as API consumers are concerned. However, we could improve efficiency for some usage patterns by providing an alternative to dblink.getcontents that is oriented toward case-insensitive handling. For example, every single dblink._match_contents call currently has to transform all names to lowercase, and generate a reverse mapping from lowercase back to preserved case. The dblink._match_contents method would be more efficient if we created an alternative to dblink.getcontents that handled the transformations and cached the results. I intentionally did not implement this optimization yet, since it's probably better to do it in a separate patch, rather than complicate the current patch. But if you think this is the best way, I'm not going to stand in the way of this patch. As discussed above, think the current approach is pretty reasonable, though I would like to optimize it with a separate patch. -- Thanks, Zac
[gentoo-portage-dev] [PATCH] fs_template._ensure_dirs: handle EEXIST (529120)
There was a race inside fs_template._ensure_dirs which could cause it to raise EEXIST if a concurrent process created the directory after os.path.exists returned False. Fix it by using the util.ensure_dirs function, which already handles EEXIST. X-Gentoo-Bug: 529120 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=529120 --- pym/portage/cache/fs_template.py | 25 ++--- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/pym/portage/cache/fs_template.py b/pym/portage/cache/fs_template.py index de4fe4b..fa44abc 100644 --- a/pym/portage/cache/fs_template.py +++ b/pym/portage/cache/fs_template.py @@ -10,7 +10,7 @@ from portage import os from portage.proxy.lazyimport import lazyimport lazyimport(globals(), 'portage.exception:PortageException', - 'portage.util:apply_permissions', + 'portage.util:apply_permissions,ensure_dirs', ) del lazyimport @@ -61,20 +61,15 @@ class FsBased(template.database): for dir in path.lstrip(os.path.sep).rstrip(os.path.sep).split(os.path.sep): base = os.path.join(base,dir) - if not os.path.exists(base): - if self._perms != -1: - um = os.umask(0) - try: - perms = self._perms - if perms == -1: - perms = 0 - perms |= 0o755 - os.mkdir(base, perms) - if self._gid != -1: - os.chown(base, -1, self._gid) - finally: - if self._perms != -1: - os.umask(um) + if ensure_dirs(base): + # We only call apply_permissions if ensure_dirs created + # a new directory, so as not to interfere with + # permissions of existing directories. + mode = self._perms + if mode == -1: + mode = 0 + mode |= 0o755 + apply_permissions(base, mode=mode, gid=self._gid) def _prune_empty_dirs(self): all_dirs = [] -- 2.0.4
[gentoo-portage-dev] [PATCH] portageq: fix eroot parameter (bug #529200)
The portageq eroot parameter has been broken since commit
c9f6aa9f0151adb3c86706eaef1914cdbdcf2b6d, due to premature instantiation
of portage.settings (before the ROOT variable was set). Premature access
to the portage.settings attribute must be avoided by using other
available means to determine the EPREFIX.
Fixes: c9f6aa9f0151 (Add cross-prefix support)
X-Gentoo-Bug: 529200
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=529200
---
bin/portageq| 9 -
pym/portage/tests/emerge/test_simple.py | 10 --
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/bin/portageq b/bin/portageq
index 009f116..ef565d1 100755
--- a/bin/portageq
+++ b/bin/portageq
@@ -1392,7 +1392,14 @@ def main(argv):
sys.stderr.write(Run portageq with --help for info\n)
sys.stderr.flush()
sys.exit(os.EX_USAGE)
- eprefix = portage.settings[EPREFIX]
+ # Calculate EPREFIX and ROOT that will be used to construct
+ # portage.settings later. It's tempting to use
+ # portage.settings[EPREFIX] here, but that would force
+ # instantiation of portage.settings, which we don't want to do
+ # until after we've calculated ROOT (see bug #529200).
+ eprefix = os.environ.get(EPREFIX, portage.const.EPREFIX)
+ if eprefix:
+ eprefix = portage.util.normalize_path(eprefix)
eroot = portage.util.normalize_path(argv[2])
if eprefix:
diff --git a/pym/portage/tests/emerge/test_simple.py
b/pym/portage/tests/emerge/test_simple.py
index 6c20a07..0101362 100644
--- a/pym/portage/tests/emerge/test_simple.py
+++ b/pym/portage/tests/emerge/test_simple.py
@@ -217,6 +217,8 @@ pkg_preinst() {
self.assertFalse(test_ebuild is None)
cross_prefix = os.path.join(eprefix, cross_prefix)
+ cross_root = os.path.join(eprefix, cross_root)
+ cross_eroot = os.path.join(cross_root, eprefix.lstrip(os.sep))
test_commands = (
env_update_cmd,
@@ -318,6 +320,10 @@ pkg_preinst() {
portageq_cmd + (has_version, cross_prefix,
dev-libs/A),
({EPREFIX : cross_prefix},) + \
portageq_cmd + (has_version, cross_prefix,
dev-libs/B),
+
+ # Test ROOT support
+ ({ROOT: cross_root},) + emerge_cmd + (dev-libs/B,),
+ portageq_cmd + (has_version, cross_eroot,
dev-libs/B),
)
distdir = playground.distdir
@@ -372,8 +378,8 @@ pkg_preinst() {
os.environ[__PORTAGE_TEST_HARDLINK_LOCKS]
updates_dir = os.path.join(test_repo_location, profiles,
updates)
- dirs = [cachedir, cachedir_pregen, cross_prefix, distdir,
fake_bin,
- portage_tmpdir, updates_dir,
+ dirs = [cachedir, cachedir_pregen, cross_eroot, cross_prefix,
+ distdir, fake_bin, portage_tmpdir, updates_dir,
user_config_dir, var_cache_edb]
etc_symlinks = (dispatch-conf.conf, etc-update.conf)
# Override things that may be unavailable, or may have
portability
--
2.0.4
