[gentoo-dev] Re: check-reqs* vs CFLAGS=-g
On Fri, 2 Aug 2013 13:47:10 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On Fri, Aug 2, 2013 at 1:08 PM, Andreas K. Huettel dilfri...@gentoo.orgwrote: I thought -O0 was generally discouraged, even for debugging?! As Michał said, it all depends on what you want to debug. I would say that for 90% of issues you *do not* want to use -O0. Your code might not even compile (libav for instance used to rely heavily in the DCE pass being executed, GCC disables DCE at -O0), and even if it, you're now given a different program altogether, so if you're looking for a crash, it might magically disappear (memory areas get cleared out at -O0 but they might be re-used without clearing at any other -O level). If you're feeling adventurous you could try -Og -g with gcc 4.8. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: check-reqs* vs CFLAGS=-g
On Thu, 1 Aug 2013 13:33:48 +0200 Michał Górny mgo...@gentoo.org wrote: What can we do to improve this? I'm not really happy to have LLVM ebuild analyze CFLAGS to set proper space constraints. Maybe we should make check-reqs-r1 automatically bump the constraints by some statistical multiplier when it detects -g? The problem with that is there is no way to determine how much larger a -g build will be. It varies widely across GCC versions (eg. when var-tracking was added the size of debug info exploded, in some cases up to an order of magnitude), and different -g/-ggdb levels. All you can really do is warn people they may run out of space if they're using debugging options. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: renaming gentoo-oldnet
Probably not a big deal, but there is a “~/.netrc” file which holds usernames and password for various services (some FTP clients use it, maybe others). Chris https://github.com/kr/netrc https://metacpan.org/module/Net::Netrc ^ too much evidence of prior work And worse, Net::Netrc is part of the standard perl distribution, and has been so since 5.7.3 aka 11 years ago. -- Kent
Re: [gentoo-dev] Re: renaming gentoo-oldnet
On 5 August 2013 17:33, Christopher Head ch...@chead.ca wrote: Probably not a big deal, but there is a “~/.netrc” file which holds usernames and password for various services (some FTP clients use it, maybe others). If you want a suggestion that imbues all the things we want to imbue, and isn't a recognised name already, I suggest opennetrc. Sure, its a bit of a mouthful, but a quick search only reveals people trying to open the netrc file, which is not really a namespace collision. And although it conveys the heritage of openrc, it doesn't bind itself to being dependent on openrc. -- Kent
[gentoo-dev] Remember to specify SLOT when adding subslot operator to dependencies
This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Neither of which are correct, since dev-libs/openssl has SLOT=0 and SLOT=0.9.8 and virtual/jpeg has SLOT=0 and SLOT=62. Need to pull in the SLOT that installs headers: dev-libs/openssl:0= virtual/jpeg:0= Same logic applies to any package with also binary-only SLOTs that install libfoobar.so.1 and nothing else. Thanks, Samuli
Re: [gentoo-dev] Remember to specify SLOT when adding subslot operator to dependencies
Dnia 2013-08-05, o godz. 12:33:45 Samuli Suominen ssuomi...@gentoo.org napisał(a): This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Neither of which are correct, since dev-libs/openssl has SLOT=0 and SLOT=0.9.8 and virtual/jpeg has SLOT=0 and SLOT=62. Need to pull in the SLOT that installs headers: dev-libs/openssl:0= virtual/jpeg:0= Same logic applies to any package with also binary-only SLOTs that install libfoobar.so.1 and nothing else. Sounds like it's easy to miss that someone added binary-only SLOTs to a package. Is there anything we can do to improve this? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
Picked random mail from this thread. So, I've seen many people raising intrest in keeping IUSE=static in cryptsetup and lvm2 but I haven't really seen anyone working on it yet, except _AxS_ committed one patch but that isn't enough. Take eg. http://bugs.gentoo.org/show_bug.cgi?id=472692#c4 The user raised very valid question in the bug... The current answer seems to be Nobody maintains this package for static linking, sorry. So I'll be removing IUSE=static from said packages if they still fail after week or so, like they do today and have for past months. - Samuli
Re: [gentoo-dev] Remember to specify SLOT when adding subslot operator to dependencies
On 08/05/2013 11:49 AM, Michał Górny wrote: Dnia 2013-08-05, o godz. 12:33:45 Samuli Suominen ssuomi...@gentoo.org napisał(a): This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Neither of which are correct, since dev-libs/openssl has SLOT=0 and SLOT=0.9.8 and virtual/jpeg has SLOT=0 and SLOT=62. Need to pull in the SLOT that installs headers: dev-libs/openssl:0= virtual/jpeg:0= Same logic applies to any package with also binary-only SLOTs that install libfoobar.so.1 and nothing else. Sounds like it's easy to miss that someone added binary-only SLOTs to a package. Is there anything we can do to improve this? Name the slot properly. 62-binary
[gentoo-dev] Re: Global USE flag: git
On Sat, 03 Aug 2013 16:19:16 +0200 hasufell hasuf...@gentoo.org wrote: I find it a bit silly to require discussing global useflags on dev-ML. The purpose of the discussion is to come up with a description that is general enough to apply to most ebuilds that use that flag. It's a throwback to when global and local flags had to be exclusive so you had to be careful about the wording. Nowadays where you can have a local description override a global one it's less important, but not completely so. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On 5/08/2013 19:33, Samuli Suominen wrote: This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Is there any reason for the subslot operator being specified at all? I don't see those packages defining any subslots.
Re: [gentoo-dev] Re: Global USE flag: git
On Mon, Aug 5, 2013 at 6:56 AM, Ryan Hill dirtye...@gentoo.org wrote: On Sat, 03 Aug 2013 16:19:16 +0200 hasufell hasuf...@gentoo.org wrote: I find it a bit silly to require discussing global useflags on dev-ML. The purpose of the discussion is to come up with a description that is general enough to apply to most ebuilds that use that flag. It's a throwback to when global and local flags had to be exclusive so you had to be careful about the wording. Nowadays where you can have a local description override a global one it's less important, but not completely so. It isn't a bad idea to still post on -dev. Maintainers should be removing the local definitions, and just because a decision seems like the obviously-correct one doesn't mean that it is. Usually when a decision is obviously-correct there isn't a great deal of bikeshedding. There weren't any replies at all to the original email beyond the discussion on whether it needs discussion. There have been cases where proposals have been made to globalize a use flag only to have it come up that the meaning of the flag really wasn't consistent. Rich
Re: [gentoo-dev] Re: Global USE flag: git
On 08/05/2013 01:01 PM, Rich Freeman wrote: It isn't a bad idea to still post on -dev. Maintainers should be removing the local definitions, and just because a decision seems like the obviously-correct one doesn't mean that it is. Follow-up question: Should _I_ remove the identical local definitions as non-maint commit? 12:38 AM, Michael Weber wrote: git - Enable git (version control system) support NO - different description : app-admin/pass:git - Use dev-vcs/git for password revisions. app-editors/gedit-plugins:git - Shows document changes related to git's HEAD dev-util/metro:git - Enable support for git snapshots sys-devel/gettext:git - When running `autopoint`, use git to store the internal development files; this requires git at runtime, but will be faster/smaller than raw archives YES - approx. same description: app-portage/layman:git - Support dev-vcs/git based overlays dev-python/anyvc:git - Add support for Git dev-qt/qt-creator:git - Add support for dev-vcs/git version control system dev-util/monodevelop:git - Enable Git version control support dev-vcs/cvs2svn:git - Support for dev-vcs/git dev-vcs/fromcvs:git - Add support for conversion to dev-vcs/git repositories dev-vcs/rabbitvcs:git - Enable plugin for dev-vcs/git kde-base/dolphin-plugins:git - Enable support for the git VCS xfce-extra/thunar-vcs-plugin:git - Enable dev-vcs/git support -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Re: Global USE flag: git
On 08/05/2013 01:10 PM, Michael Weber wrote: On 08/05/2013 01:01 PM, Rich Freeman wrote: It isn't a bad idea to still post on -dev. Maintainers should be removing the local definitions, and just because a decision seems like the obviously-correct one doesn't mean that it is. Follow-up question: Should _I_ remove the identical local definitions as non-maint commit? 12:38 AM, Michael Weber wrote: git - Enable git (version control system) support NO - different description : app-admin/pass:git - Use dev-vcs/git for password revisions. app-editors/gedit-plugins:git - Shows document changes related to git's HEAD dev-util/metro:git - Enable support for git snapshots sys-devel/gettext:git - When running `autopoint`, use git to store the internal development files; this requires git at runtime, but will be faster/smaller than raw archives don't change anything that looks only slightly different I personally feel that descriptions should be as clear as possible. They generic ones in use.desc often tell you nothing and are really only a fallback. YES - approx. same description: app-portage/layman:git - Support dev-vcs/git based overlays don't change dev-python/anyvc:git - Add support for Git remove dev-qt/qt-creator:git - Add support for dev-vcs/git version control system remove dev-util/monodevelop:git - Enable Git version control support remove dev-vcs/cvs2svn:git - Support for dev-vcs/git remove dev-vcs/fromcvs:git - Add support for conversion to dev-vcs/git repositories don't change dev-vcs/rabbitvcs:git - Enable plugin for dev-vcs/git don't change kde-base/dolphin-plugins:git - Enable support for the git VCS remove xfce-extra/thunar-vcs-plugin:git - Enable dev-vcs/git support remove
[gentoo-dev] USE flag descriptions
Currently, USE flag descriptions are a mix of imperative (Enable) and indicative (Enables) forms, the former occuring more often: Enable : Enables = 2143 : 408 Add : Adds = 525 : 341 Build : Builds = 833 : 27 Use : Uses = 619 : 11 Install : Installs = 511 : 49 etc. Any objections if I change the global descriptions in use.desc to the imperative form? Ulrich
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On 05/08/13 13:56, Michael Palimaka wrote: On 5/08/2013 19:33, Samuli Suominen wrote: This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Is there any reason for the subslot operator being specified at all? I don't see those packages defining any subslots. You don't need to see it, because portage sets implicit subslot /0 in EAPI=5 so it's there, even if you don't see it. Then when it's changed (= set), the effect is same. - Samuli
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 05 Aug 2013, Samuli Suominen wrote: You don't need to see it, because portage sets implicit subslot /0 in EAPI=5 so it's there, even if you don't see it. Shouldn't the implicit sub-slot be equal to the regular slot? Ulrich
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Aug 5, 2013 8:06 AM, Ulrich Mueller u...@gentoo.org wrote: On Mon, 05 Aug 2013, Samuli Suominen wrote: You don't need to see it, because portage sets implicit subslot /0 in EAPI=5 so it's there, even if you don't see it. Shouldn't the implicit sub-slot be equal to the regular slot? Ulrich Yes, as per EAPI 5 [1], implicit sub-slots are equal to that of the regular slot. As these packages depend specifically on slot 0, the deps could be changed to virtual/jpeg:0 and virtual/openssl:0 respectively, and then updated later should another compatible slot come along (as they'd need to be anyway). Granted, you then lose the automatic rebuild if these packages start using subslots, so it's probably best to leave the slot operator dep. -Doug [1]: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-820008.2.6
[gentoo-dev] Unused global USE flags
No package has the following flags in IUSE, so I'll remove them in a
few days from now:
kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT} if enabled or
into /usr (FHS compatible) otherwise
nocxx - Old flag -- USE=cxx from now on
Ulrich
[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On 5/08/2013 21:58, Samuli Suominen wrote: On 05/08/13 13:56, Michael Palimaka wrote: On 5/08/2013 19:33, Samuli Suominen wrote: This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Is there any reason for the subslot operator being specified at all? I don't see those packages defining any subslots. You don't need to see it, because portage sets implicit subslot /0 in EAPI=5 so it's there, even if you don't see it. Then when it's changed (= set), the effect is same. - Samuli Even though the subslot is implicit, is that any reason to still use the operator? We don't know what the maintainer's future intentions for the subslot will be. For example, we caused many useless rebuilds with poppler because dependants added the subslot operator without consideration (many packages link only against one of the stable interface libraries, rather than the main library for which the subslot was intended).
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, Aug 5, 2013 at 11:00 AM, Michael Palimaka kensing...@gentoo.org wrote: Even though the subslot is implicit, is that any reason to still use the operator? We don't know what the maintainer's future intentions for the subslot will be. For example, we caused many useless rebuilds with poppler because dependants added the subslot operator without consideration (many packages link only against one of the stable interface libraries, rather than the main library for which the subslot was intended). That seems more of an issue with the design of slot operators - any particular upgrade of a library package doesn't necessarily break ABI on all of the library files it installs. I suspect most maintainers would rather upgrade their package once to EAPI5 and not keep checking back every month to see if there is a new opportunity to add another slot operator dep. If maintainers don't add them up-front even with the deps don't support them, chances are they'll never add them. How often does this situation even come up? If 9/10 times the libraries are set up as maintainers expect them to be, it is probably better to deal with the odd unnecessary rebuild until somebody spots it, rather than going without support for slot operator deps. Rich
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On 05/08/13 18:00, Michael Palimaka wrote: On 5/08/2013 21:58, Samuli Suominen wrote: On 05/08/13 13:56, Michael Palimaka wrote: On 5/08/2013 19:33, Samuli Suominen wrote: This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Is there any reason for the subslot operator being specified at all? I don't see those packages defining any subslots. You don't need to see it, because portage sets implicit subslot /0 in EAPI=5 so it's there, even if you don't see it. Then when it's changed (= set), the effect is same. - Samuli Even though the subslot is implicit, is that any reason to still use the operator? We don't know what the maintainer's future intentions for the subslot will be. For example, we caused many useless rebuilds with poppler because dependants added the subslot operator without consideration (many packages link only against one of the stable interface libraries, rather than the main library for which the subslot was intended). The plan is to change SLOT of virtual/jpeg from 0 to eg. 0/1 after next SONAME change in the default of the virtual, so it's useful to have everything depend on virtual/jpeg:0= ready, to get the benefits of the subslot. This is different than poppler, this is just single shared library package, like eg. libpng, tiff, lcms, ... where as poppler has many different backends and own libraries for them.
[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On 6/08/2013 01:06, Samuli Suominen wrote: The plan is to change SLOT of virtual/jpeg from 0 to eg. 0/1 after next SONAME change in the default of the virtual, so it's useful to have everything depend on virtual/jpeg:0= ready, to get the benefits of the subslot. Does that mean that anyone that uses media-libs/jpeg instead of libjpeg-turbo will be forced to needlessly rebuild half their system when the latter is bumped?
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 05 Aug 2013 18:06:33 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: The plan is to change SLOT of virtual/jpeg from 0 to eg. 0/1 after next SONAME change in the default of the virtual, so it's useful to have everything depend on virtual/jpeg:0= ready, to get the benefits of the subslot. last I heard subslots on virtuals didnt work that well: https://bugs.gentoo.org/show_bug.cgi?id=449094 and this plan is broken: changing the subslot on the virtual will trigger the rebuilds but will likely not ensure all the providers have changed soname, so there is a case of completely useless rebuilds. I would rather wait for the above bug to be fixed and have a proper way to handle subslots through virtuals than converting packages to := depend on the virtual. Alexis.
Re: [gentoo-dev] renaming gentoo-oldnet
[snip] :p I'm actually thinking netrc if Robin is ok with it. William replaying to a random message in the tree Not going to suggest a name but if has to be something for general consumption, it should avoid the gentoo inside the name just my 0.2¢
[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On 6/08/2013 01:07, Rich Freeman wrote: I suspect most maintainers would rather upgrade their package once to EAPI5 and not keep checking back every month to see if there is a new opportunity to add another slot operator dep. If maintainers don't add them up-front even with the deps don't support them, chances are they'll never add them. Historically, I have seen library maintainers asking consumer maintainers to add the subslot operator, where appropriate, after correctly implementing the subslot. How often does this situation even come up? If 9/10 times the libraries are set up as maintainers expect them to be, it is probably better to deal with the odd unnecessary rebuild until somebody spots it, rather than going without support for slot operator deps. With respect, good enough is not a very high standard to aim for. In my opinion, adding unnecessary subslot dependencies is no different to adding overly-wide dependencies. We already have preserved-libs to prevent breakage. Subslots should be an improvement on this, not causing a regression.
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
Dnia 2013-08-05, o godz. 11:50:38 Alexis Ballier aball...@gentoo.org napisał(a): On Mon, 05 Aug 2013 18:06:33 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: The plan is to change SLOT of virtual/jpeg from 0 to eg. 0/1 after next SONAME change in the default of the virtual, so it's useful to have everything depend on virtual/jpeg:0= ready, to get the benefits of the subslot. last I heard subslots on virtuals didnt work that well: https://bugs.gentoo.org/show_bug.cgi?id=449094 and this plan is broken: changing the subslot on the virtual will trigger the rebuilds but will likely not ensure all the providers have changed soname, so there is a case of completely useless rebuilds. I would rather wait for the above bug to be fixed and have a proper way to handle subslots through virtuals than converting packages to := depend on the virtual. We can simply have multiple virtual versions, each depending on the proper jpeg jpeg-turbo versions. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Unused global USE flags
Am Montag, 5. August 2013, 15:39:48 schrieb Ulrich Mueller:
No package has the following flags in IUSE, so I'll remove them in a
few days from now:
kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT} if
enabled or into /usr (FHS compatible) otherwise
kdeprefix is long gone, it should really be removed from the descriptions.
--
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 06 Aug 2013 02:03:28 +1000 Michael Palimaka kensing...@gentoo.org wrote: How often does this situation even come up? If 9/10 times the libraries are set up as maintainers expect them to be, it is probably better to deal with the odd unnecessary rebuild until somebody spots it, rather than going without support for slot operator deps. With respect, good enough is not a very high standard to aim for. In my opinion, adding unnecessary subslot dependencies is no different to adding overly-wide dependencies. There's a world of difference between a horrible breakage and an occasional unnecessary compile. If users are concerned about how they spend their CPU time, they're using the wrong distribution. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 18:10:46 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-08-05, o godz. 11:50:38 Alexis Ballier aball...@gentoo.org napisał(a): On Mon, 05 Aug 2013 18:06:33 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: The plan is to change SLOT of virtual/jpeg from 0 to eg. 0/1 after next SONAME change in the default of the virtual, so it's useful to have everything depend on virtual/jpeg:0= ready, to get the benefits of the subslot. last I heard subslots on virtuals didnt work that well: https://bugs.gentoo.org/show_bug.cgi?id=449094 and this plan is broken: changing the subslot on the virtual will trigger the rebuilds but will likely not ensure all the providers have changed soname, so there is a case of completely useless rebuilds. I would rather wait for the above bug to be fixed and have a proper way to handle subslots through virtuals than converting packages to := depend on the virtual. We can simply have multiple virtual versions, each depending on the proper jpeg jpeg-turbo versions. you can do it that way, yes. what will you do when jpeg 10 is out or when libjpeg-turbo changes its abi ? wait for each provider to have a release that changes the abi ? this doesnt sound sane
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 17:13:49 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 06 Aug 2013 02:03:28 +1000 Michael Palimaka kensing...@gentoo.org wrote: How often does this situation even come up? If 9/10 times the libraries are set up as maintainers expect them to be, it is probably better to deal with the odd unnecessary rebuild until somebody spots it, rather than going without support for slot operator deps. With respect, good enough is not a very high standard to aim for. In my opinion, adding unnecessary subslot dependencies is no different to adding overly-wide dependencies. There's a world of difference between a horrible breakage and an occasional unnecessary compile. If users are concerned about how they spend their CPU time, they're using the wrong distribution. there is something wrong in the way its done if there are 'occasional unnecessary compiles' 'horrible breakage' is mitigated by preserve-libs and running @preserved-rebuild as soon as possible has the same end result avoiding useless rebuilds.
[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On 6/08/2013 02:13, Ciaran McCreesh wrote: On Tue, 06 Aug 2013 02:03:28 +1000 Michael Palimaka kensing...@gentoo.org wrote: How often does this situation even come up? If 9/10 times the libraries are set up as maintainers expect them to be, it is probably better to deal with the odd unnecessary rebuild until somebody spots it, rather than going without support for slot operator deps. With respect, good enough is not a very high standard to aim for. In my opinion, adding unnecessary subslot dependencies is no different to adding overly-wide dependencies. There's a world of difference between a horrible breakage and an occasional unnecessary compile. If users are concerned about how they spend their CPU time, they're using the wrong distribution. To which horrible breakage are you referring?
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 12:22:32 -0400 Alexis Ballier aball...@gentoo.org wrote: On Mon, 5 Aug 2013 17:13:49 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 06 Aug 2013 02:03:28 +1000 Michael Palimaka kensing...@gentoo.org wrote: How often does this situation even come up? If 9/10 times the libraries are set up as maintainers expect them to be, it is probably better to deal with the odd unnecessary rebuild until somebody spots it, rather than going without support for slot operator deps. With respect, good enough is not a very high standard to aim for. In my opinion, adding unnecessary subslot dependencies is no different to adding overly-wide dependencies. There's a world of difference between a horrible breakage and an occasional unnecessary compile. If users are concerned about how they spend their CPU time, they're using the wrong distribution. there is something wrong in the way its done if there are 'occasional unnecessary compiles' Not really. There's a tradeoff between dependencies that are occasionally too strict, and dependencies that are horribly complicated (see subslot dictionaries). Gentoo already favours lots of unnecessary recompiling over additional complexity. For example, for many revbumps, it would be possible to only rebuild a small part of the package and replace a few files rather than the whole thing. But writing ebuilds capable of doing so would involve more developer work, and would be more prone to screwups, so such a feature isn't offered. So all this fuss over unnecessary compiles is misplaced. Gentoo simply isn't the right distribution to use if minimising compile time is a goal. 'horrible breakage' is mitigated by preserve-libs and running @preserved-rebuild as soon as possible has the same end result avoiding useless rebuilds. But preserve-libs introduces breakages and security holes. The point of slot operator dependencies is to replace that with a reliable feature that doesn't rely upon guesswork and voodoo. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
Am Montag, 5. August 2013, 18:22:32 schrieb Alexis Ballier: 'horrible breakage' is mitigated by preserve-libs and running @preserved-rebuild as soon as possible has the same end result avoiding useless rebuilds. No it is not and does not. [Providing roughly the same information depth in my statement as well, deliberately.] -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 17:36:49 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 5 Aug 2013 12:22:32 -0400 Alexis Ballier aball...@gentoo.org wrote: On Mon, 5 Aug 2013 17:13:49 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 06 Aug 2013 02:03:28 +1000 Michael Palimaka kensing...@gentoo.org wrote: How often does this situation even come up? If 9/10 times the libraries are set up as maintainers expect them to be, it is probably better to deal with the odd unnecessary rebuild until somebody spots it, rather than going without support for slot operator deps. With respect, good enough is not a very high standard to aim for. In my opinion, adding unnecessary subslot dependencies is no different to adding overly-wide dependencies. There's a world of difference between a horrible breakage and an occasional unnecessary compile. If users are concerned about how they spend their CPU time, they're using the wrong distribution. there is something wrong in the way its done if there are 'occasional unnecessary compiles' Not really. There's a tradeoff between dependencies that are occasionally too strict, and dependencies that are horribly complicated (see subslot dictionaries). having a way to express 'my subslot is the one of my provider' doesnt seem overly complicated Gentoo already favours lots of unnecessary recompiling over additional complexity. For example, for many revbumps, it would be possible to only rebuild a small part of the package and replace a few files rather than the whole thing. But writing ebuilds capable of doing so would involve more developer work, and would be more prone to screwups, so such a feature isn't offered. So all this fuss over unnecessary compiles is misplaced. Gentoo simply isn't the right distribution to use if minimising compile time is a goal. two wrongs do not make one right... esp. when the 'wrong' at hand can be easily avoided... 'horrible breakage' is mitigated by preserve-libs and running @preserved-rebuild as soon as possible has the same end result avoiding useless rebuilds. But preserve-libs introduces breakages and security holes. The point of slot operator dependencies is to replace that with a reliable feature that doesn't rely upon guesswork and voodoo. not more than subslots, per pms: The sub-slot is used to represent cases in which an upgrade to a new version of a package with a different sub-slot may require dependent packages to be rebuilt. so, per spec, it isnt reliable either since the spec does not enforce rebuilds as soon as possible, heck, it doesnt even enforces rebuilds... (may vs must + when) in the present example, the spec allows the following scenario leaving your system in a broken state and triggering useless rebuilds: - update virtual/jpeg with new subslot - rebuild all dependent packages - update provider of virtual/jpeg
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 18:37:29 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Montag, 5. August 2013, 18:22:32 schrieb Alexis Ballier: 'horrible breakage' is mitigated by preserve-libs and running @preserved-rebuild as soon as possible has the same end result avoiding useless rebuilds. No it is not and does not. [Providing roughly the same information depth in my statement as well, deliberately.] if there is something you disagree with / dont understand, please state it so that i can clarify
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, Aug 5, 2013 at 12:15 PM, Alexis Ballier aball...@gentoo.org wrote: On Mon, 5 Aug 2013 18:10:46 +0200 Michał Górny mgo...@gentoo.org wrote: We can simply have multiple virtual versions, each depending on the proper jpeg jpeg-turbo versions. you can do it that way, yes. what will you do when jpeg 10 is out or when libjpeg-turbo changes its abi ? wait for each provider to have a release that changes the abi ? this doesnt sound sane I think a thorough solution needs to handle the passthrough situation, and ideally the multiple libs per package situation. Our whole versioning system wasn't really set up with this stuff in mind either. We're dealing with ABI/SONAME versions here - not functionality versions. A package with jpeg-turbo SONAME 0.6 might be a superset of all the functionality in SONAME 0.9 - the larger number doesn't mean better, just different. It might still be possible to handle this with subslots as they are currently implemented, but I'd have to really mess around with it to be sure. The logic of higher-number = more-desirable is likely to cause problems - you don't want your system to force you to move from jpeg-turbo to jpeg because only the latter is a dep of a newer virtual. Rich
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 12:51:48 -0400 Alexis Ballier aball...@gentoo.org wrote: Not really. There's a tradeoff between dependencies that are occasionally too strict, and dependencies that are horribly complicated (see subslot dictionaries). having a way to express 'my subslot is the one of my provider' doesnt seem overly complicated Unfortunately things that don't seem to be complicated sometimes are complicated. We haven't established whether that's the case here. In particular, we don't have any notion of providers currently, and it's not clear such a concept makes sense as-is. We haven't worked out what happens in a || ( a b !c ) case where a, b and c are all installed, for example. So all this fuss over unnecessary compiles is misplaced. Gentoo simply isn't the right distribution to use if minimising compile time is a goal. two wrongs do not make one right... esp. when the 'wrong' at hand can be easily avoided... We've not established that it's easy. 'horrible breakage' is mitigated by preserve-libs and running @preserved-rebuild as soon as possible has the same end result avoiding useless rebuilds. But preserve-libs introduces breakages and security holes. The point of slot operator dependencies is to replace that with a reliable feature that doesn't rely upon guesswork and voodoo. not more than subslots, per pms: The sub-slot is used to represent cases in which an upgrade to a new version of a package with a different sub-slot may require dependent packages to be rebuilt. so, per spec, it isnt reliable either since the spec does not enforce rebuilds as soon as possible, heck, it doesnt even enforces rebuilds... (may vs must + when) You are misreading that statement. The may is there because even in cases where there is an ABI break, some dependent packages may not require recompiling because they may not be using the full ABI. The may means developers are not prohibited from changing subslots in the case where there exists a package which will not break. Also, as soon as possible doesn't come into it anywhere. It's not even a well defined requirement. Also also, the spec generally avoids wordings that prohibit the package manager from breaking things (partly because Portage doesn't properly enforce dependencies, partly because prohibiting the user from breaking things if they really want to is not the Gentoo way). The spec prefers to state things in terms of what can be relied upon to work. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 18:28:54 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 5 Aug 2013 12:51:48 -0400 Alexis Ballier aball...@gentoo.org wrote: Not really. There's a tradeoff between dependencies that are occasionally too strict, and dependencies that are horribly complicated (see subslot dictionaries). having a way to express 'my subslot is the one of my provider' doesnt seem overly complicated Unfortunately things that don't seem to be complicated sometimes are complicated. We haven't established whether that's the case here. In particular, we don't have any notion of providers currently, s/currently/anymore/ and it's not clear such a concept makes sense as-is. We haven't worked out what happens in a || ( a b !c ) case where a, b and c are all installed, for example. subslot = concatenation of the subslots of all (positive? if it makes sense) dependencies; updated when said dependencies get their subslot changed. this seems to fit well for a virtual and should be in line with what one would get with old style virtuals in mind. So all this fuss over unnecessary compiles is misplaced. Gentoo simply isn't the right distribution to use if minimising compile time is a goal. two wrongs do not make one right... esp. when the 'wrong' at hand can be easily avoided... We've not established that it's easy. you don't believe it is; and the first part still applies, meaning we should avoid to do the wrong thing just because there are other areas where we got it wrong. 'horrible breakage' is mitigated by preserve-libs and running @preserved-rebuild as soon as possible has the same end result avoiding useless rebuilds. But preserve-libs introduces breakages and security holes. The point of slot operator dependencies is to replace that with a reliable feature that doesn't rely upon guesswork and voodoo. not more than subslots, per pms: The sub-slot is used to represent cases in which an upgrade to a new version of a package with a different sub-slot may require dependent packages to be rebuilt. so, per spec, it isnt reliable either since the spec does not enforce rebuilds as soon as possible, heck, it doesnt even enforces rebuilds... (may vs must + when) You are misreading that statement. The may is there because even in cases where there is an ABI break, some dependent packages may not require recompiling because they may not be using the full ABI. The may means developers are not prohibited from changing subslots in the case where there exists a package which will not break. how can one know if that 'may' applies ? Also, as soon as possible doesn't come into it anywhere. It's not even a well defined requirement. read it differently then: foo has := dependencies that changed their subslot after foo has been installed. Is a DEPEND on foo considered satisfied or should foo be rebuilt before ? Also also, the spec generally avoids wordings that prohibit the package manager from breaking things (partly because Portage doesn't properly enforce dependencies, partly because prohibiting the user from breaking things if they really want to is not the Gentoo way). The spec prefers to state things in terms of what can be relied upon to work. Supposing we are dealing with shared libraries only, how is that an improvement over preserve-libs ?
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On 05/08/13 18:06, Samuli Suominen wrote: On 05/08/13 18:00, Michael Palimaka wrote: On 5/08/2013 21:58, Samuli Suominen wrote: On 05/08/13 13:56, Michael Palimaka wrote: On 5/08/2013 19:33, Samuli Suominen wrote: This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Is there any reason for the subslot operator being specified at all? I don't see those packages defining any subslots. You don't need to see it, because portage sets implicit subslot /0 in EAPI=5 so it's there, even if you don't see it. Then when it's changed (= set), the effect is same. - Samuli Even though the subslot is implicit, is that any reason to still use the operator? We don't know what the maintainer's future intentions for the subslot will be. For example, we caused many useless rebuilds with poppler because dependants added the subslot operator without consideration (many packages link only against one of the stable interface libraries, rather than the main library for which the subslot was intended). The plan is to change SLOT of virtual/jpeg from 0 to eg. 0/1 after next SONAME change in the default of the virtual, so it's useful to have everything depend on virtual/jpeg:0= ready, to get the benefits of the subslot. This is different than poppler, this is just single shared library package, like eg. libpng, tiff, lcms, ... where as poppler has many different backends and own libraries for them. [ .. ] okay, maybe this plan sucks as some have suggested in later posts in this thread. however the main point from first post stands, don't at least do virtual/jpeg:= deps, use at least virtual/jpeg:0 or virtual/jpeg:0= whatever
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 13:58:49 -0400 Alexis Ballier aball...@gentoo.org wrote: Unfortunately things that don't seem to be complicated sometimes are complicated. We haven't established whether that's the case here. In particular, we don't have any notion of providers currently, s/currently/anymore/ Well the old definition won't do what you want... and it's not clear such a concept makes sense as-is. We haven't worked out what happens in a || ( a b !c ) case where a, b and c are all installed, for example. subslot = concatenation of the subslots of all (positive? if it makes sense) dependencies; updated when said dependencies get their subslot changed. Have you established that that's the correct behaviour in every (or any) case where these will be used? So all this fuss over unnecessary compiles is misplaced. Gentoo simply isn't the right distribution to use if minimising compile time is a goal. two wrongs do not make one right... esp. when the 'wrong' at hand can be easily avoided... We've not established that it's easy. you don't believe it is; and the first part still applies, meaning we should avoid to do the wrong thing just because there are other areas where we got it wrong. I disagree with your assertion that the occasional unnecessary rebuild is wrong, when one considers the cost of avoiding it. Do you really want developers to have to manually check and specify exactly which symbols their package uses from every single slottable dependency? Such a list could easily run to thousands of entries per dependency. You are misreading that statement. The may is there because even in cases where there is an ABI break, some dependent packages may not require recompiling because they may not be using the full ABI. The may means developers are not prohibited from changing subslots in the case where there exists a package which will not break. how can one know if that 'may' applies ? Package manglers are expected to assume that it could apply. Ebuild developers are not expected to guarantee that it will, since providing that guarantee is very very difficult and would require knowledge of exactly which symbols are used by every dependent of a package. Also, as soon as possible doesn't come into it anywhere. It's not even a well defined requirement. read it differently then: foo has := dependencies that changed their subslot after foo has been installed. Is a DEPEND on foo considered satisfied or should foo be rebuilt before ? That's covered by the spec. Basically, ignoring many of the complications that make dependency resolution such a pain, for a dependency to be usable, all its dependencies must be usable. The may there is simply there to avoid prohibiting developers from doing a subslot bump when it could turn out not to be necessary after all. Also also, the spec generally avoids wordings that prohibit the package manager from breaking things (partly because Portage doesn't properly enforce dependencies, partly because prohibiting the user from breaking things if they really want to is not the Gentoo way). The spec prefers to state things in terms of what can be relied upon to work. Supposing we are dealing with shared libraries only, how is that an improvement over preserve-libs ? We aren't dealing with shared libraries only. Even if we were, a) shared libraries have dependencies upon things that are not shared libraries, like text files, and b) subslots don't facilitate using an old, insecure shared library to generate content. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, Aug 5, 2013 at 2:09 PM, Samuli Suominen ssuomi...@gentoo.org wrote: okay, maybe this plan sucks as some have suggested in later posts in this thread. however the main point from first post stands, don't at least do virtual/jpeg:= deps, use at least virtual/jpeg:0 or virtual/jpeg:0= whatever ++ That at much makes sense when a package actually has slots. Actually virtual/jpeg:0 also makes sense even if you're not using subslot deps. Rich
Re: [gentoo-dev] renaming gentoo-oldnet
I'm replying the start of this thread, rather than picking a single person to respond to. I DO want more brainstorming on ideas for the naming of the package, and I think people need to cast a wider net for naming ideas. I'm most certainly not planning to get rid of the package whatsoever, many of my systems have complex configurations that are made MUCH easier with oldnet than any other network configuration system I have found. Goals of gentoo-oldnet: - Make oldnet functionality available to users of other init systems [1][2] - If a package upstream is forcing you towards systemd, you shouldn't have to lose other very useful packages. - Seperate out development cycle from core OpenRC - oldnet accounts for more than 30% of OpenRC bugs, and a large fraction of the codebase. History of the oldnet name: - It's only called oldnet because when Roy introduced 'newnet', what we consider to be 'oldnet' didn't actually have a separate name. Various proposed names (in no specific order): - openrc-oldnet (implies OpenRC, and has 'old'). - openrc-gentoo-net (implies OpenRC) - gentoo-networking (does this mean newnet is here too?) - gen-net (ditto) - netrc (conflicts) - opennetrc (implies OpenRC) - 'net run control' (hard to search) - 'net run configuration' (hard to search) - multi-net (conflicts) - netctl (conflicts) - netcfg (conflicts) - netconf (conflicts) - enet (conflicts) - posixsh-netconf (conflicts netconf) - nettool (conflicts) - netcfgtool (conflicts) - posixnet (conflicts) - shnettool Naming goals: - Should describe what it does - Does NOT have a name conflict as verified by Google. - Does NOT imply OpenRC. - Implying Gentoo is fine, as it's where the package comes from. - Should drop 'old' I think we should focus on the first goal the most: oldnet is a network configuring tool in pure POSIX shell So we probably want the substring 'net' somewhere in there. Beyond that, all suggestions are welcome. [1] There was a failed GSOC project that I mentioned several years ago, that was to support ALL openrc style init.d scripts on Upstart, so oldnet would have worked implicitly. Unfortunately the student didn't actually do ANY work. [2] The configuration itself ends up broken into two parts: - directives that control the startup dependency tree. - directives that control the actual configuration. The former will need to be interoperable or exported to other init systems in some way (hopefully dynamically), the latter can stay the same. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] renaming gentoo-oldnet
On Mon, 5 Aug 2013 22:09:54 + Robin H. Johnson robb...@gentoo.org wrote: Naming goals: - Should describe what it does - Does NOT have a name conflict as verified by Google. - Does NOT imply OpenRC. - Implying Gentoo is fine, as it's where the package comes from. - Should drop 'old' I think we should focus on the first goal the most: oldnet is a network configuring tool in pure POSIX shell So we probably want the substring 'net' somewhere in there. Beyond that, all suggestions are welcome. Here are a couple of suggestions: net-init (or netinit) - without the dash the only conflict appears to be a matlab script of some sort
Re: [gentoo-dev] renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/06/2013 12:09 AM, Robin H. Johnson wrote: I'm replying the start of this thread, rather than picking a single person to respond to. I DO want more brainstorming on ideas for the naming of the package, and I think people need to cast a wider net for naming ideas. I'm most certainly not planning to get rid of the package whatsoever, many of my systems have complex configurations that are made MUCH easier with oldnet than any other network configuration system I have found. Goals of gentoo-oldnet: - Make oldnet functionality available to users of other init systems [1][2] - If a package upstream is forcing you towards systemd, you shouldn't have to lose other very useful packages. - Seperate out development cycle from core OpenRC - oldnet accounts for more than 30% of OpenRC bugs, and a large fraction of the codebase. History of the oldnet name: - It's only called oldnet because when Roy introduced 'newnet', what we consider to be 'oldnet' didn't actually have a separate name. Various proposed names (in no specific order): - openrc-oldnet (implies OpenRC, and has 'old'). - openrc-gentoo-net (implies OpenRC) - gentoo-networking (does this mean newnet is here too?) - gen-net (ditto) - netrc (conflicts) - opennetrc (implies OpenRC) - 'net run control' (hard to search) - 'net run configuration' (hard to search) - multi-net (conflicts) - netctl (conflicts) - netcfg (conflicts) - netconf (conflicts) - enet (conflicts) - posixsh-netconf (conflicts netconf) - nettool (conflicts) - netcfgtool (conflicts) - posixnet (conflicts) - shnettool Naming goals: - Should describe what it does - Does NOT have a name conflict as verified by Google. - Does NOT imply OpenRC. - Implying Gentoo is fine, as it's where the package comes from. - Should drop 'old' I think we should focus on the first goal the most: oldnet is a network configuring tool in pure POSIX shell So we probably want the substring 'net' somewhere in there. Beyond that, all suggestions are welcome. [1] There was a failed GSOC project that I mentioned several years ago, that was to support ALL openrc style init.d scripts on Upstart, so oldnet would have worked implicitly. Unfortunately the student didn't actually do ANY work. [2] The configuration itself ends up broken into two parts: - directives that control the startup dependency tree. - directives that control the actual configuration. The former will need to be interoperable or exported to other init systems in some way (hopefully dynamically), the latter can stay the same. Adding some proposals: - - altnetrc (as it is an alternative) - - galtnet (gentoo + alternative + network) - - altgnet (same, permuted) - - anetcfg (alternative + network + configuration) - - netposh (network + posix + shell) - - psnetconf (posix shell network configuration) - - maybe this one is inspirational, too: https://en.wikipedia.org/wiki/Gannet Kind regards, Manuel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSACk5XxSAAC4AKGlzc3Vlci0uLi5Abm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcW3MP/iu+n+SPJ50tfrfWyrONXj8v m5mABJtK8DkX/KVdOpr1YWKv3DJVB4Nx6iGSh4PW/jdkVeRmIOJLwipMX3aqpCGi T0dxQrmTwYyJ1+F6oF9UJiFAtTQ1jhNDlBcc/AqajPwWuMOKHGiHeyrROqnUakiA /BeZ02a28TMy+stwMaiKT/4DvoIQX/chi5CLdiPOk1uKxnhC7yfSZvh+WFcYh7SW iW3LQrPO+fiHLrKxr7GlFQ86RTg2A0ySjrpbBYhsYSePkDuRZkAQ8hB1wzDayvek p6zLgHh7qaFREndnSnWhK2Pk7IZ/FqF+MFodW0j6Wv3BTxf0CDoDiWvkIrrrAXfe w2YfzBgQfOtPmARQegWQn2PhsM+F9jPCvA0r2GrSm92i6F9pQ7sHGjniL1Wj4nwA H7YYkAK6Vh23NM49evTragrIWAPtNFKAtyrMVHhGcMYy9gXWKQW1HgxW6N4Mxmv7 OO3SkzS5FNU7rrwbL9thGoRwLifTj9jzLIi3Kb2xcyC2Cxl99JxYq1tgwXYYDkEM Kywqug/sAe5RXk2dfqrVspkOZzppsZYo5ffa7ddPZJGqSdKIqgOqn0TuDh/v1sWZ sUol5N0hr56KjG6a3oiHdjxbqj9CiWNGO5n6/AhUbEIccyg5Ug2TTamfMDYqnXPj DCIE9KqaYxIQA30CyTen =4zrW -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 19:13:06 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: and it's not clear such a concept makes sense as-is. We haven't worked out what happens in a || ( a b !c ) case where a, b and c are all installed, for example. subslot = concatenation of the subslots of all (positive? if it makes sense) dependencies; updated when said dependencies get their subslot changed. Have you established that that's the correct behaviour in every (or any) case where these will be used? No, but this sounds like a tradeoff between useless subslots for virtuals and more general considerations... If you want something that works in every case it'll obviously be more complicated. So all this fuss over unnecessary compiles is misplaced. Gentoo simply isn't the right distribution to use if minimising compile time is a goal. two wrongs do not make one right... esp. when the 'wrong' at hand can be easily avoided... We've not established that it's easy. you don't believe it is; and the first part still applies, meaning we should avoid to do the wrong thing just because there are other areas where we got it wrong. I disagree with your assertion that the occasional unnecessary rebuild is wrong, when one considers the cost of avoiding it. Do you really want developers to have to manually check and specify exactly which symbols their package uses from every single slottable dependency? Such a list could easily run to thousands of entries per dependency. No, this assumes it is done correctly and independently of subslots: soname change iff ABI is not backward compatible. A soname change requires the rebuild, regardless of the symbols used. You are misreading that statement. The may is there because even in cases where there is an ABI break, some dependent packages may not require recompiling because they may not be using the full ABI. The may means developers are not prohibited from changing subslots in the case where there exists a package which will not break. how can one know if that 'may' applies ? Package manglers are expected to assume that it could apply. Ebuild developers are not expected to guarantee that it will, since providing that guarantee is very very difficult and would require knowledge of exactly which symbols are used by every dependent of a package. Again, symbols have nothing to do here. Since you have poor control on overlays and absolutely zero control on locally built packages, the only sane assumption is that all symbols are used. Also, as soon as possible doesn't come into it anywhere. It's not even a well defined requirement. read it differently then: foo has := dependencies that changed their subslot after foo has been installed. Is a DEPEND on foo considered satisfied or should foo be rebuilt before ? That's covered by the spec. Basically, ignoring many of the complications that make dependency resolution such a pain, for a dependency to be usable, all its dependencies must be usable. The may there is simply there to avoid prohibiting developers from doing a subslot bump when it could turn out not to be necessary after all. And then when a package has various libraries, one being very unstable abi-wise and the others stable, it seems much more sane not to := depend on said package if you only use the stable ones when the subslot clearly refers to the unstable abi library. Also also, the spec generally avoids wordings that prohibit the package manager from breaking things (partly because Portage doesn't properly enforce dependencies, partly because prohibiting the user from breaking things if they really want to is not the Gentoo way). The spec prefers to state things in terms of what can be relied upon to work. Supposing we are dealing with shared libraries only, how is that an improvement over preserve-libs ? We aren't dealing with shared libraries only. Even if we were, a) shared libraries have dependencies upon things that are not shared libraries, like text files, and b) subslots don't facilitate using an old, insecure shared library to generate content. I don't see how current subslots improve a) and b) is just a matter of UI defaults...
Re: [gentoo-dev] renaming gentoo-oldnet
On Mon, Aug 05, 2013 at 10:09:54PM +, Robin H. Johnson wrote Naming goals: - Should describe what it does - Does NOT have a name conflict as verified by Google. - Does NOT imply OpenRC. - Implying Gentoo is fine, as it's where the package comes from. - Should drop 'old' Some suggestions, keying in on the fact that it's shellscript-based - netshell or netshellrc - shellnet or shellnetrc - bashnet or bashnetrc - ashnet or ashnetrc Note that the rc suffix does not imply OpenRC, e.g... [i660][waltdnes][~] ll /etc/*rc -rw-r--r-- 1 root root 1484 Jun 14 08:17 /etc/drirc -rw-r--r-- 1 root root 1304 Jul 27 20:30 /etc/eixrc -rw-r--r-- 1 root root 1855 Feb 14 2010 /etc/inputrc -rw-r--r-- 1 root root 125 May 13 09:27 /etc/mail.rc -rw-r--r-- 1 root root 8949 Jul 4 12:53 /etc/nanorc -rw-r--r-- 1 root root 77 Jun 14 04:11 /etc/procmailrc -rw-r--r-- 1 root root 4479 Jun 14 02:54 /etc/wgetrc -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] renaming gentoo-oldnet
On 08/05/2013 06:09 PM, Robin H. Johnson wrote: - netrc (conflicts) Would naming it net-rc alleviate the perceived conflict?
Re: [gentoo-dev] renaming gentoo-oldnet
On 08/05/2013 09:45 PM, Michael Orlitzky wrote: On 08/05/2013 06:09 PM, Robin H. Johnson wrote: - netrc (conflicts) Would naming it net-rc alleviate the perceived conflict? Or, duh, networkrc.
