Re: [gentoo-dev] renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/06/2013 12:09 AM, Robin H. Johnson wrote: Various proposed names (in no specific order): names, *sigh* It's rather a interface setup utility than a networking thing. Networkin happens - most cases - when you have paths and entities and such - so: genif - for GENtoo InterFace (relativley free on google) geco - GEntoo COnnect (taken by ammunition and multi-national) most penguin/cow related names are taken and dictionary words are taken. enp3s0 - just 4,380 hits gif - *trololo* - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlIAlJ0ACgkQknrdDGLu8JB7RAD7BykNyuToczgom047oMvE2asl AzasM2xBNDjnIrM/9r0A/1C8KX79YaqpihgiyCJYOEcyEpRrJLscn639oCN55jdo =Eqvz -END PGP SIGNATURE-
Re: [gentoo-dev] renaming gentoo-oldnet
On 06/08/2013 00:09, 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. The software was originally called net, right? Perhaps not officially, but certainly colloquially. Why not just keep the name net and leave other newer systems to come up with their own names? I do agree that modifiers old and new are bad ideas - they come about because of the environment and no the software itself. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] USE flag descriptions
On Mon, 5 Aug 2013 13:57:55 +0200 Ulrich Mueller u...@gentoo.org wrote: 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? Sounds good. jer
[gentoo-dev] status of security improvments (GLEPs 57-61)
It seems none of them (except the overview GLEP 57) are implemented yet, although they are roughly 6-8 years old. What is holding it back? Is it just that we don't have a PM implementation yet or is it some political nonsense and PMS blocking progress again? I am not criticizing the portage team in any way here. I just want to push for some attention. -- http://www.gentoo.org/proj/en/glep/glep-0057.html http://www.gentoo.org/proj/en/glep/glep-0058.html http://www.gentoo.org/proj/en/glep/glep-0059.html http://www.gentoo.org/proj/en/glep/glep-0060.html http://www.gentoo.org/proj/en/glep/glep-0061.html https://bugs.gentoo.org/show_bug.cgi?id=64258 http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/13 12:10 PM, Michał Górny 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. ...except it doesn't end up being that simple. Making sure the virtual and the dependents link up properly requires PDEPENDS on the dependents as well as proper DEPENDS on the virtuals, and = deps (which don't play nice with anything). But yes, this is the best option at this point. [tangent] If it were still supported, what *would* work best would be the old PROVIDES= syntax within the dependent ebuilds. The main issue with sub-slot propagation is the fact that it needs to propagate through these 'virtual' packages. Except they aren't packages, they're just an alias for a set of (R)DEPEND values. The more i've thought about this, the more I'm thinking virtuals should be treated differently than what we're currently doing... [/tangent] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBAx0ACgkQ2ugaI38ACPAelQD+Ot+Jb3MVGy1pT+JDdWJ62g9D m4JcxZbohFI9Zblt6LYA/2ZQ2E7QByGLWaHMomrK0B5cSK7GNH3sJh9PrfXHgn5S =fXu5 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/13 12:51 PM, Alexis Ballier wrote: 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 That's not subslot-dictionaries, tho -- sub-slot dictionaries is the solution proposed to handle i.e. the poppler case, so there are two (or more) sub-slots, one for the main lib and one for the less-changing client lib, so that consumers can trigger rebuilds on just the portion that matters instead of every time. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBBBUACgkQ2ugaI38ACPDUcwD/XnGZymkRn5+YHF7cXAo6URtC 2058nmFx90ROUBtgIngA/RXa23UWACMLH2J7lZlNsCJBkfRPZ95BL7aeyBvKDdxM =AkWd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/08/13 01:07 PM, Rich Freeman wrote:
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.
This is the primary reason as to why sub-slots were designed as they
were, to be an independently set value -- it allows the maintainer of
say, jpeg-turbo to bump the subslot value only when necessary (for
instance, in the case of SONAME 0.6 being a complete superset of 0.9,
there is no need to bump sub-slot as long as it is known that all
consumers are only consuming the subset of functions available in 0.9
(and if they aren't, I expect there's going to be compile-time
breakage anyhow).
This is starting to go off-topic, but it's one of the reasons I don't
like seeing packages with SLOT=0/${PV} or similar -- to me, a
sub-slot bump should really be evaluated on its own merits and not
just for any version bump.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
iF4EAREIAAYFAlIBBZwACgkQ2ugaI38ACPCuuAD9HhPrGA5A7BN4FM8X58la/r0+
wpzueqNlPFAk9WCZkScA/0gfqkYP9GuAFBtQPq8zbEiEqX8DDRZ03FQYISSlrv8B
=bSZH
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/13 01:58 PM, Alexis Ballier wrote: 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. Except that's going to trigger even more of these unnecessary rebuilds that you wanted to avoid -- what if a user has both libjpeg-turbo and jpeg installed? Then a change in one (even if that package wasn't built against it) is going to trigger a rebuild of everything depending on the virtual. As would, I expect, the emerge or unmerge of one of them, too. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBBoAACgkQ2ugaI38ACPDD9gEAnOUU1AAqzBVo1WrRlXgZULIk hjq2zFB+2q8Bw9IE5skA/0SGkHrlOpYsvOJs1XSZhEPWL507eO9UMDIp4YsTM+IJ =xNSp -END PGP SIGNATURE-
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
On 06/08/13 10:02 AM, hasufell wrote: It seems none of them (except the overview GLEP 57) are implemented yet, although they are roughly 6-8 years old. What is holding it back? Is it just that we don't have a PM implementation yet or is it some political nonsense and PMS blocking progress again? I am not criticizing the portage team in any way here. I just want to push for some attention. -- http://www.gentoo.org/proj/en/glep/glep-0057.html http://www.gentoo.org/proj/en/glep/glep-0058.html http://www.gentoo.org/proj/en/glep/glep-0059.html http://www.gentoo.org/proj/en/glep/glep-0060.html http://www.gentoo.org/proj/en/glep/glep-0061.html https://bugs.gentoo.org/show_bug.cgi?id=64258 http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709 AFAIK, the status is unimplemented, and nobody's working on it. I believe that the reason is simply that nobody has done the work yet, not due to bikeshedding. I agree that these should be implemented at a rate faster than the current one (i.e. not at all). (FYI, you spelled improvements wrong. ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/08/13 10:21 AM, Ian Stakenvicius wrote: On 05/08/13 01:58 PM, Alexis Ballier wrote: 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. Except that's going to trigger even more of these unnecessary rebuilds that you wanted to avoid -- what if a user has both libjpeg-turbo and jpeg installed? Then a change in one (even if that package wasn't built against it) is going to trigger a rebuild of everything depending on the virtual. As would, I expect, the emerge or unmerge of one of them, too. Now, if there was a way to determine the particular package (and its subslot value) via the SCANELF info (not possible I don't think), or if we were to implement virtual/jpeg as an exclusive-or instead of an inclusive-or (will break when two packages depend on explicit, different versions of libjpeg), then this could work more like what is expected. ... more research needed ... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBCp8ACgkQ2ugaI38ACPBeVgD9H5LAWDyLNjoRaWGtrOoLN35X Va/uEo9v7Wzc5psNt0cA/RZygrlCB70LDHX+vUJE/616xbUxWD/GjpvqVR7G/rok =xzxc -END PGP SIGNATURE-
Re: [gentoo-dev] renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/13 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 alternatively, rc-net ? (google seems to reference 'rc' as 'remote control' as in race cars, airplanes, etc; but given /etc/rc.* and /etc/init* have been around forever and have always been called the rc system, i think we should be safe using it) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBDGkACgkQ2ugaI38ACPDXWQD/Y4LVerIupWiP3Z9smg/FEUIA 1mNGhvLXuWuel18PEdYA/iGoixmYUiO5h2AlDBf2gIepsa+3cMfHW1zS6MhaDmxT =n7pZ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 06 Aug 2013 10:21:52 -0400 Ian Stakenvicius a...@gentoo.org wrote: 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. Except that's going to trigger even more of these unnecessary rebuilds that you wanted to avoid -- what if a user has both libjpeg-turbo and jpeg installed? the assumption behind this is that it is not possible
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Mon, 5 Aug 2013 18:49:49 -0400 Alexis Ballier aball...@gentoo.org wrote: 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. And that answers your question as to why the spec says may. 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. But that leads to breakage when the stable ABI changes. It's better to avoid breakage than it is to require the odd extra recompile. 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) With subslots, the developer specifies dependencies. With fix-linkage, the package mangler has to guess based upon very incomplete information. and b) is just a matter of UI defaults... No, b) doesn't happen with correctly done subslots. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 16:25:12 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 5 Aug 2013 18:49:49 -0400 Alexis Ballier aball...@gentoo.org wrote: 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. And that answers your question as to why the spec says may. Not really: This explains why there _must_ be another way than subslots to check this. elf libraries have soname, some other systems that lack it, such as ocaml, have quite restrictive build time/runtime checks to avoid messing up. If I build locally a program of mine that all of a sudden starts to provide me false results because nobody told me I had to rebuild it, I'd be quite upset. Changing soname is the well established standard notification for this. With a soname change it's not really a 'may' but rather a 'must'... same with ocaml for example. 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. But that leads to breakage when the stable ABI changes. It's better to avoid breakage than it is to require the odd extra recompile. That's why preserve-libs is still the proper way to do it until we have a more accurate subslot handling. In the poppler case, the stable ABI changes an order of magnitude less often than the unstable one; it's not really 'the' extra recompile but rather hundreds of them if you multiply by the # of dependent packages. Claiming it's better to have hundreds of recompiles is simply being lazy, throwing our failures onto users, and not be willing to fix the real problem. 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) With subslots, the developer specifies dependencies. With fix-linkage, the package mangler has to guess based upon very incomplete information. You're assuming library maintainers are stupid: If done properly, there is a library that gives you the text file location based on where it has been installed. If that's not the case then that's where I'd try to improve things, not hiding the problem behind a subslot. and b) is just a matter of UI defaults... No, b) doesn't happen with correctly done subslots. neither with a preserve-libs implementation that, by default, would run @preserved-rebuild after detecting there are preserved libraries and would refuse to merge anything but the broken packages if there are preserved libraries.
Re: [gentoo-dev] renaming gentoo-oldnet
On Mon, Aug 05, 2013 at 10:09:54PM +, 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. Robin, I would like the decision to be made soon. I need to release OpenRc-0.12 in the next day or so, and if I do not have the answer I will have to do the split in OpenRc-0.13. I thought of a name based on your last suggestion and a comment on the list. Instead of networkrc, maybe netifrc (network interface rc). So, my choices, in no particular order, would be, netifrc, networkrc or, if neither of those fly, keep gentoo-oldnet. If we change away from gentoo-oldnet, we will need to open an infrastructure bug to change the name of the overlay, the bugzilla account and the component in bugzilla before we can take bugs for the new package. Thoughts anyone? William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 12:16:57 -0400 Alexis Ballier aball...@gentoo.org wrote: On Tue, 6 Aug 2013 16:25:12 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 5 Aug 2013 18:49:49 -0400 Alexis Ballier aball...@gentoo.org wrote: 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. And that answers your question as to why the spec says may. Not really: This explains why there _must_ be another way than subslots to check this. Only if you want to avoid ever having an unnecessary rebuild. That isn't a sensible goal. But that leads to breakage when the stable ABI changes. It's better to avoid breakage than it is to require the odd extra recompile. That's why preserve-libs is still the proper way to do it until we have a more accurate subslot handling. preserve-libs is broken by design. All you need is proper use of subslots, and to recognise that the occasional unnecessary rebuild isn't a big deal. In the poppler case, the stable ABI changes an order of magnitude less often than the unstable one; it's not really 'the' extra recompile but rather hundreds of them if you multiply by the # of dependent packages. Claiming it's better to have hundreds of recompiles is simply being lazy, throwing our failures onto users, and not be willing to fix the real problem. There's an easy fix for that: split the package up. With subslots, the developer specifies dependencies. With fix-linkage, the package mangler has to guess based upon very incomplete information. You're assuming library maintainers are stupid: If done properly, there is a library that gives you the text file location based on where it has been installed. If that's not the case then that's where I'd try to improve things, not hiding the problem behind a subslot. That's no good when that file is removed or overwritten by a newer format, but preserve-libs leaves the .so that uses that file behind. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 17:30:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 12:16:57 -0400 Alexis Ballier aball...@gentoo.org wrote: On Tue, 6 Aug 2013 16:25:12 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 5 Aug 2013 18:49:49 -0400 Alexis Ballier aball...@gentoo.org wrote: 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. And that answers your question as to why the spec says may. Not really: This explains why there _must_ be another way than subslots to check this. Only if you want to avoid ever having an unnecessary rebuild. That isn't a sensible goal. You haven't read the part you cut it seems. But that leads to breakage when the stable ABI changes. It's better to avoid breakage than it is to require the odd extra recompile. That's why preserve-libs is still the proper way to do it until we have a more accurate subslot handling. preserve-libs is broken by design. All you need is proper use of subslots, and to recognise that the occasional unnecessary rebuild isn't a big deal. preserve-libs has its flaws. All you need is improving the subslot system so that it can be used properly. What are you waiting for ? :) 'occasional unnecessary rebuild' is a big deal since subslots introduce this regression... In the poppler case, the stable ABI changes an order of magnitude less often than the unstable one; it's not really 'the' extra recompile but rather hundreds of them if you multiply by the # of dependent packages. Claiming it's better to have hundreds of recompiles is simply being lazy, throwing our failures onto users, and not be willing to fix the real problem. There's an easy fix for that: split the package up. Great, please start submitting patches at our thousands of upstreams so that their packages can be split properly. With subslots, the developer specifies dependencies. With fix-linkage, the package mangler has to guess based upon very incomplete information. You're assuming library maintainers are stupid: If done properly, there is a library that gives you the text file location based on where it has been installed. If that's not the case then that's where I'd try to improve things, not hiding the problem behind a subslot. That's no good when that file is removed or overwritten by a newer format, but preserve-libs leaves the .so that uses that file behind. Then submit patches to run preserve-libs as soon as possible as I suggested in the part you cut. preserve-libs, in contrast to just removing the .so, leaves you with a working system in 90% of the cases. Exercise: Try to update a FreeBSD 6 system (libc.so.6) to a FreeBSD 7 system (libc.so.7) without some kind of preserve-libs mechanism. Been there, done that. The flaws of preserve-libs show up but it maintains a half working system all the way long that allows you to finish the update.
Re: [gentoo-dev] renaming gentoo-oldnet
Am Dienstag, 6. August 2013, 11:26:16 schrieb William Hubbs: On Mon, Aug 05, 2013 at 10:09:54PM +, 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. Robin, I would like the decision to be made soon. I need to release OpenRc-0.12 in the next day or so, and if I do not have the answer I will have to do the split in OpenRc-0.13. I thought of a name based on your last suggestion and a comment on the list. Instead of networkrc, maybe netifrc (network interface rc). So, my choices, in no particular order, would be, netifrc, networkrc or, if neither of those fly, keep gentoo-oldnet. If we change away from gentoo-oldnet, we will need to open an infrastructure bug to change the name of the overlay, the bugzilla account and the component in bugzilla before we can take bugs for the new package. Thoughts anyone? My 2¢: * Keep a simple but straight forward and technical name * Do not use *rc as this implies an oldschool configuration filename Some more suggestions: * openrc-net (if it is coupled to openrc) * rcnet * gentoo-networking * gentoo-netconf * netconf Or maybe * larry-net ;-) -Marc -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 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, 6 Aug 2013 13:05:07 -0400 Alexis Ballier aball...@gentoo.org wrote: 'occasional unnecessary rebuild' is a big deal since subslots introduce this regression... Er, no. Subslots just simplify the way accurate slot dependencies are expressed. That's all they are: an alternative to having a larger number of (full) slots plus blockers between some of those slots. There's an easy fix for that: split the package up. Great, please start submitting patches at our thousands of upstreams so that their packages can be split properly. You don't need to patch anything... You just make poppler-stable and poppler-dodgy ebuilds. Then submit patches to run preserve-libs as soon as possible as I suggested in the part you cut. preserve-libs, in contrast to just removing the .so, leaves you with a working system in 90% of the cases. preserve-libs is broken by design. Tweaking when it's run won't fix that breakage. Exercise: Try to update a FreeBSD 6 system (libc.so.6) to a FreeBSD 7 system (libc.so.7) without some kind of preserve-libs mechanism. Been there, done that. The flaws of preserve-libs show up but it maintains a half working system all the way long that allows you to finish the update. There is no half working. Something is either correct or it isn't. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 18:41:59 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 13:05:07 -0400 Alexis Ballier aball...@gentoo.org wrote: 'occasional unnecessary rebuild' is a big deal since subslots introduce this regression... Er, no. Subslots just simplify the way accurate slot dependencies are expressed. That's all they are: an alternative to having a larger number of (full) slots plus blockers between some of those slots. hmmm... no ? There's an easy fix for that: split the package up. Great, please start submitting patches at our thousands of upstreams so that their packages can be split properly. You don't need to patch anything... You just make poppler-stable and poppler-dodgy ebuilds. And you need to patch it to do it properly. Or you can do parts/subpackages or subslot dictionaries to express that. Proper splitting is easy to ask but harder to do in practice; you're starting to make me believe you're only on the PM writing side without much experience on how real life packages are. Then submit patches to run preserve-libs as soon as possible as I suggested in the part you cut. preserve-libs, in contrast to just removing the .so, leaves you with a working system in 90% of the cases. preserve-libs is broken by design. Tweaking when it's run won't fix that breakage. Exercise: Try to update a FreeBSD 6 system (libc.so.6) to a FreeBSD 7 system (libc.so.7) without some kind of preserve-libs mechanism. Been there, done that. The flaws of preserve-libs show up but it maintains a half working system all the way long that allows you to finish the update. There is no half working. Something is either correct or it isn't. Sometimes there is no 'correct'. You are probably using every day programs that use heuristics/approximations to solve NP-hard or undecidable problems in a 'correct enough' way.
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 14:12:06 -0400 Alexis Ballier aball...@gentoo.org wrote: On Tue, 6 Aug 2013 18:41:59 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 13:05:07 -0400 Alexis Ballier aball...@gentoo.org wrote: 'occasional unnecessary rebuild' is a big deal since subslots introduce this regression... Er, no. Subslots just simplify the way accurate slot dependencies are expressed. That's all they are: an alternative to having a larger number of (full) slots plus blockers between some of those slots. hmmm... no ? Er, yes. You may be confusing subslots and :=/:* dependencies, which are a different feature. There's an easy fix for that: split the package up. Great, please start submitting patches at our thousands of upstreams so that their packages can be split properly. You don't need to patch anything... You just make poppler-stable and poppler-dodgy ebuilds. And you need to patch it to do it properly. You just make the ebuilds install different bits. In effect you emulate a simple subset of how parts would do it. Or you can do parts/subpackages or subslot dictionaries to express that. Realistically, parts will never get implemented in Portage. Subslot dictionaries might be, if anyone ever figures out what they're supposed to be, but they're a heavy price for package developers to pay. The question under discussion is whether it's a price worth paying to avoid an occasional unnecessary rebuild. Since users do far more unnecessary rebuilds for other reasons anyway, and reducing CPU usage has never been a goal for Gentoo, I'm not convinced it's worth caring about. Exercise: Try to update a FreeBSD 6 system (libc.so.6) to a FreeBSD 7 system (libc.so.7) without some kind of preserve-libs mechanism. Been there, done that. The flaws of preserve-libs show up but it maintains a half working system all the way long that allows you to finish the update. There is no half working. Something is either correct or it isn't. Sometimes there is no 'correct'. You are probably using every day programs that use heuristics/approximations to solve NP-hard or undecidable problems in a 'correct enough' way. Dependency resolution is at least NP hard, and we're still solving it exactly. But you're confusing approximations and feasibility here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 19:25:15 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 14:12:06 -0400 Alexis Ballier aball...@gentoo.org wrote: On Tue, 6 Aug 2013 18:41:59 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 13:05:07 -0400 Alexis Ballier aball...@gentoo.org wrote: 'occasional unnecessary rebuild' is a big deal since subslots introduce this regression... Er, no. Subslots just simplify the way accurate slot dependencies are expressed. That's all they are: an alternative to having a larger number of (full) slots plus blockers between some of those slots. hmmm... no ? Er, yes. You may be confusing subslots and :=/:* dependencies, which are a different feature. Well, ok, but this doesn't relate to what I was writing. Subslot, or slot emulators or whatever, in their current usage with := dependencies, are not fine grained enough for some use cases. Those cause regressions if used improperly. There's an easy fix for that: split the package up. Great, please start submitting patches at our thousands of upstreams so that their packages can be split properly. You don't need to patch anything... You just make poppler-stable and poppler-dodgy ebuilds. And you need to patch it to do it properly. You just make the ebuilds install different bits. In effect you emulate a simple subset of how parts would do it. Which needs patching to be done properly... unless you are suggesting to build it twice and throw away whats not needed just to workaround subslots limitations. Or you can do parts/subpackages or subslot dictionaries to express that. Realistically, parts will never get implemented in Portage. Subslot dictionaries might be, if anyone ever figures out what they're supposed to be, but they're a heavy price for package developers to pay. The question under discussion is whether it's a price worth paying to avoid an occasional unnecessary rebuild. Since users do far more unnecessary rebuilds for other reasons anyway, and reducing CPU usage has never been a goal for Gentoo, I'm not convinced it's worth caring about. Meanwhile, there's preserve-libs :) Your argumentation is basically 'Other parts are doing it wrong so it's ok to add some more to it'... We're back a dozen emails back, aren't we? Exercise: Try to update a FreeBSD 6 system (libc.so.6) to a FreeBSD 7 system (libc.so.7) without some kind of preserve-libs mechanism. Been there, done that. The flaws of preserve-libs show up but it maintains a half working system all the way long that allows you to finish the update. There is no half working. Something is either correct or it isn't. Sometimes there is no 'correct'. You are probably using every day programs that use heuristics/approximations to solve NP-hard or undecidable problems in a 'correct enough' way. Dependency resolution is at least NP hard, and we're still solving it exactly. But you're confusing approximations and feasibility here. It was meant as an example and has nothing to do with dependency resolution. The above exercise is something extreme but that we have to solve; preserve-libs has proven to be correct enough. You have yet to show a correct, in your sense, solution.
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 15:31:14 -0400 Alexis Ballier aball...@gentoo.org wrote: Well, ok, but this doesn't relate to what I was writing. Subslot, or slot emulators or whatever, in their current usage with := dependencies, are not fine grained enough for some use cases. Those cause regressions if used improperly. There is no regression. Previously, packages sometimes broke when doing an upgrade. Now, packages do not break when doing an upgrade. You just make the ebuilds install different bits. In effect you emulate a simple subset of how parts would do it. Which needs patching to be done properly... unless you are suggesting to build it twice and throw away whats not needed just to workaround subslots limitations. It's up to the relevant developers to decide how much work they're willing to put in to save some users a bit of CPU time. Or you can do parts/subpackages or subslot dictionaries to express that. Realistically, parts will never get implemented in Portage. Subslot dictionaries might be, if anyone ever figures out what they're supposed to be, but they're a heavy price for package developers to pay. The question under discussion is whether it's a price worth paying to avoid an occasional unnecessary rebuild. Since users do far more unnecessary rebuilds for other reasons anyway, and reducing CPU usage has never been a goal for Gentoo, I'm not convinced it's worth caring about. Meanwhile, there's preserve-libs :) Which causes breakage. Your argumentation is basically 'Other parts are doing it wrong so it's ok to add some more to it'... We're back a dozen emails back, aren't we? It's not adding more to it. It's avoiding eliminating a tiny portion of it. Even if you subscribe to the notion that unnecessary rebuilds are a relevant problem, there's no point in caring about the occasional unnecessary rebuild due to overly strict dependencies when most unnecessary rebuilds are caused by something else entirely. It was meant as an example and has nothing to do with dependency resolution. The above exercise is something extreme but that we have to solve; preserve-libs has proven to be correct enough. You have yet to show a correct, in your sense, solution. The correct solution is heavy slotting. And I'd hardly consider intermittently introduces invisible security holes and causes unbootable systems to be correct enough... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/07/13 04:42 AM, Samuli Suominen wrote: cryptsetup upstream installed minimal Gentoo setup and tested our handling of 'static' and was disappointed finding them broken https://bugs.gentoo.org/show_bug.cgi?id=438998 - RESO/TEST - cryptsetup static+pcre fails (fixed via resolution of bug 439414) https://bugs.gentoo.org/show_bug.cgi?id=468400 - RESO/TEST - cryptsetup static+selinux fails (fixed via resolution of bug 439414) https://bugs.gentoo.org/show_bug.cgi?id=472692 - RESO/FIXED - cryptsetup static+ssl fails (note, only cryptsetup-1.6.1 fixed, so this should get pushed stable) https://bugs.gentoo.org/show_bug.cgi?id=462908 - RESO/FIXED - lvm2 static-libs missing library https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag missing proper description, yes this is minor https://bugs.gentoo.org/show_bug.cgi?id=370217 - RESO/FIXED - lvm2 fails to build due to missing -lrt, likely related to linking against libudev, yes the feature we are discussing to be dropped has been completely broken for ages https://bugs.gentoo.org/show_bug.cgi?id=439414 - RESO/FIXED - lvm2 static+selinux fails So dropping IUSE=static becomes a no-op now, right? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBWb8ACgkQ2ugaI38ACPC44gD8CMJO4AdXLL1SWXPxhd4UBBsL IJ4pl3zYgCCKrqS0jrcA/0geqa/gf0KTotkE0BqEeHm39pfr7VeEahKArSe8G9zE =bpUn -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 20:44:57 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 15:31:14 -0400 Alexis Ballier aball...@gentoo.org wrote: Well, ok, but this doesn't relate to what I was writing. Subslot, or slot emulators or whatever, in their current usage with := dependencies, are not fine grained enough for some use cases. Those cause regressions if used improperly. There is no regression. Previously, packages sometimes broke when doing an upgrade. Now, packages do not break when doing an upgrade. The regression is the useless rebuild. Without preserve-libs, packages break even more: cf the libc example. You just make the ebuilds install different bits. In effect you emulate a simple subset of how parts would do it. Which needs patching to be done properly... unless you are suggesting to build it twice and throw away whats not needed just to workaround subslots limitations. It's up to the relevant developers to decide how much work they're willing to put in to save some users a bit of CPU time. It's up to those that want to force this on developers to do the relevant work so that it can be done properly. Your argumentation is basically 'Other parts are doing it wrong so it's ok to add some more to it'... We're back a dozen emails back, aren't we? It's not adding more to it. It's avoiding eliminating a tiny portion of it. Even if you subscribe to the notion that unnecessary rebuilds are a relevant problem, there's no point in caring about the occasional unnecessary rebuild due to overly strict dependencies when most unnecessary rebuilds are caused by something else entirely. And here we go again... It was meant as an example and has nothing to do with dependency resolution. The above exercise is something extreme but that we have to solve; preserve-libs has proven to be correct enough. You have yet to show a correct, in your sense, solution. The correct solution is heavy slotting. And I'd hardly consider intermittently introduces invisible security holes and causes unbootable systems to be correct enough... There is no difference between heavy slotting and preserve-libs in this case.
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/08/13 04:22 PM, Alexis Ballier wrote: On Tue, 6 Aug 2013 20:44:57 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 15:31:14 -0400 Alexis Ballier aball...@gentoo.org wrote: Well, ok, but this doesn't relate to what I was writing. Subslot, or slot emulators or whatever, in their current usage with := dependencies, are not fine grained enough for some use cases. Those cause regressions if used improperly. There is no regression. Previously, packages sometimes broke when doing an upgrade. Now, packages do not break when doing an upgrade. The regression is the useless rebuild. Without preserve-libs, packages break even more: cf the libc example. Terminology issue. Useless rebuilds are not regressions. they might be undesirable, they might be bugs, but they are not something that was happening before, and then was fixed, and now is happening again. The only thing regression can be applied to in this discussion is if a consumer is NOT using a := slot-operator on a dep like poppler, and the poppler libs that consumer uses are updated and breakage occurrs - -- ie, the exact same case that was happening all the time prior to EAPI5 adoption. IE, exactly what you are proposing to do in order to reduce the extra rebuilds. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBXFYACgkQ2ugaI38ACPBwlQEAp9nVnOws3WxWyfmK7xuuCzfb sUwYmIB6lJv9G3FljpkA/RtMWa55WxihhfML9VqlQJ+HqSfP69RMTrbIjmGKufbv =PyPl -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 16:22:48 -0400 Alexis Ballier aball...@gentoo.org wrote: On Tue, 6 Aug 2013 20:44:57 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 15:31:14 -0400 Alexis Ballier aball...@gentoo.org wrote: Well, ok, but this doesn't relate to what I was writing. Subslot, or slot emulators or whatever, in their current usage with := dependencies, are not fine grained enough for some use cases. Those cause regressions if used improperly. There is no regression. Previously, packages sometimes broke when doing an upgrade. Now, packages do not break when doing an upgrade. The regression is the useless rebuild. Without preserve-libs, packages break even more: cf the libc example. You can't claim a broken solution to be better than a working solution. You just make the ebuilds install different bits. In effect you emulate a simple subset of how parts would do it. Which needs patching to be done properly... unless you are suggesting to build it twice and throw away whats not needed just to workaround subslots limitations. It's up to the relevant developers to decide how much work they're willing to put in to save some users a bit of CPU time. It's up to those that want to force this on developers to do the relevant work so that it can be done properly. No-one is forcing it on developers. Developers are free to just use lots of subslots and pass the cost on to users if they like. It's not a big deal, since Gentoo involves lots of compiling things anyway. Your argumentation is basically 'Other parts are doing it wrong so it's ok to add some more to it'... We're back a dozen emails back, aren't we? It's not adding more to it. It's avoiding eliminating a tiny portion of it. Even if you subscribe to the notion that unnecessary rebuilds are a relevant problem, there's no point in caring about the occasional unnecessary rebuild due to overly strict dependencies when most unnecessary rebuilds are caused by something else entirely. And here we go again... You've still not justified spending a massive amount of effort on addressing a tiny fraction of unnecessary recompiles. What makes this supposed problem in any way relevant? Why should we spend time reducing 1% of the cost by 1%? It was meant as an example and has nothing to do with dependency resolution. The above exercise is something extreme but that we have to solve; preserve-libs has proven to be correct enough. You have yet to show a correct, in your sense, solution. The correct solution is heavy slotting. And I'd hardly consider intermittently introduces invisible security holes and causes unbootable systems to be correct enough... There is no difference between heavy slotting and preserve-libs in this case. Yes there is: heavy slotting is only dependent upon a careful developer, whereas preserve-libs relies upon voodoo that can go horribly wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/08/13 04:17 PM, Ian Stakenvicius wrote: On 30/07/13 04:42 AM, Samuli Suominen wrote: cryptsetup upstream installed minimal Gentoo setup and tested our handling of 'static' and was disappointed finding them broken https://bugs.gentoo.org/show_bug.cgi?id=438998 - RESO/TEST - cryptsetup static+pcre fails (fixed via resolution of bug 439414) https://bugs.gentoo.org/show_bug.cgi?id=468400 - RESO/TEST - cryptsetup static+selinux fails (fixed via resolution of bug 439414) https://bugs.gentoo.org/show_bug.cgi?id=472692 - RESO/FIXED - cryptsetup static+ssl fails (note, only cryptsetup-1.6.1 fixed, so this should get pushed stable) https://bugs.gentoo.org/show_bug.cgi?id=462908 - RESO/FIXED - lvm2 static-libs missing library https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag missing proper description, yes this is minor https://bugs.gentoo.org/show_bug.cgi?id=370217 - RESO/FIXED - lvm2 fails to build due to missing -lrt, likely related to linking against libudev, yes the feature we are discussing to be dropped has been completely broken for ages https://bugs.gentoo.org/show_bug.cgi?id=439414 - RESO/FIXED - lvm2 static+selinux fails So dropping IUSE=static becomes a no-op now, right? It should also be noted that these bugs really boiled down to 2-3 changes that were quite trivial to fix. It is quite unfortunate that nobody had put the time in to figure them out and fix them, though. IUSE=static support is really not that broken, but we certainly need to step up in addressing bugs like these (and others) instead of letting them sit and fester for months. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBXZkACgkQ2ugaI38ACPBelAD+OLi+EC2pjfe2wGNkvbIL96YG U3BmlMxHTj8OYKHUNXkBAJoHlriZmdTFClf0RYNpll1206rt0fnl9dl0gc7XUukS =0bEa -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 06 Aug 2013 16:28:06 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/08/13 04:22 PM, Alexis Ballier wrote: On Tue, 6 Aug 2013 20:44:57 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 15:31:14 -0400 Alexis Ballier aball...@gentoo.org wrote: Well, ok, but this doesn't relate to what I was writing. Subslot, or slot emulators or whatever, in their current usage with := dependencies, are not fine grained enough for some use cases. Those cause regressions if used improperly. There is no regression. Previously, packages sometimes broke when doing an upgrade. Now, packages do not break when doing an upgrade. The regression is the useless rebuild. Without preserve-libs, packages break even more: cf the libc example. Terminology issue. Useless rebuilds are not regressions. they might be undesirable, they might be bugs, but they are not something that was happening before, and then was fixed, and now is happening again. Sorry, I failed to parse. They are something that was not happening before and now is happening. The only thing regression can be applied to in this discussion is if a consumer is NOT using a := slot-operator on a dep like poppler, and the poppler libs that consumer uses are updated and breakage occurrs - -- ie, the exact same case that was happening all the time prior to EAPI5 adoption. IE, exactly what you are proposing to do in order to reduce the extra rebuilds. This is not a regression from my definition: Software regression, the appearance of a bug which was absent in a previous revision http://en.wikipedia.org/wiki/Regression
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 16:39:14 -0400 Alexis Ballier aball...@gentoo.org wrote: This is not a regression from my definition: Software regression, the appearance of a bug which was absent in a previous revision A bug in this case is one of the user's packages no longer working after an upgrade, or any of the more subtle weird breakages that can be caused by preserve-libs. The user possibly having to do an extra rebuild which is not strictly necessary isn't a bug. Nothing breaks. It's just a bit more time spent compiling something every now and again, and this is a cost paid every time a package has a revision bump or version bump with only minor changes that could be handled with a partial rebuild, if only anyone cared enough to support that. Sure, in an ideal world it would be avoidable, but avoiding it shouldn't be high on the list of anyone's priorities. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Tue, 6 Aug 2013 21:33:02 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 16:22:48 -0400 Alexis Ballier aball...@gentoo.org wrote: On Tue, 6 Aug 2013 20:44:57 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 6 Aug 2013 15:31:14 -0400 Alexis Ballier aball...@gentoo.org wrote: Well, ok, but this doesn't relate to what I was writing. Subslot, or slot emulators or whatever, in their current usage with := dependencies, are not fine grained enough for some use cases. Those cause regressions if used improperly. There is no regression. Previously, packages sometimes broke when doing an upgrade. Now, packages do not break when doing an upgrade. The regression is the useless rebuild. Without preserve-libs, packages break even more: cf the libc example. You can't claim a broken solution to be better than a working solution. They're not yet comparable. What I claim is: - Preserve-libs is needed for extreme cases such as the libc or libs the compiler links to. - When used correctly, subslots provide a nice way to automate the rebuilds and correctly handle dependencies. - Current subslots and := deps do not provide all the required flexibility for real world packages. - Your proposal of not caring about it and introducing useless bloat is wrong. Your argumentation is basically 'Other parts are doing it wrong so it's ok to add some more to it'... We're back a dozen emails back, aren't we? It's not adding more to it. It's avoiding eliminating a tiny portion of it. Even if you subscribe to the notion that unnecessary rebuilds are a relevant problem, there's no point in caring about the occasional unnecessary rebuild due to overly strict dependencies when most unnecessary rebuilds are caused by something else entirely. And here we go again... You've still not justified spending a massive amount of effort on addressing a tiny fraction of unnecessary recompiles. What makes this supposed problem in any way relevant? Why should we spend time reducing 1% of the cost by 1%? You've still not done a serious analysis to back up these numbers. I'm pretty much convinced wrongly used subslot operators are now more than 50% of unnecessary recompile times. Feel free to prove me wrong, but you won't convince me by keeping repeating 'a tiny fraction of unnecessary recompiles'. Proper subslot operators is a one-time investment, reducing unnecessary compiles on the other parts likely require a constant investment over time, so in the long term, whatever the cost is, it is worth it. It was meant as an example and has nothing to do with dependency resolution. The above exercise is something extreme but that we have to solve; preserve-libs has proven to be correct enough. You have yet to show a correct, in your sense, solution. The correct solution is heavy slotting. And I'd hardly consider intermittently introduces invisible security holes and causes unbootable systems to be correct enough... There is no difference between heavy slotting and preserve-libs in this case. Yes there is: heavy slotting is only dependent upon a careful developer, whereas preserve-libs relies upon voodoo that can go horribly wrong. And also has the big advantage of providing an ancient outdated library in its proper slot so that it might be kept indefinitely.
[gentoo-dev] Response to a friendly note about changing bug reports
23:37:25 willikins rej, you have notes! [21:13] mrueg Let me
rephrase this: Just a friendly notice to please refrain from rephrasing
bug summaries from Stabilize ${P} to ${P} stable req. This just
adds unneeded noise to the bug. I don't want this on bugs I've reported
or am assigned to.
This is my equally short and friendly note: It's not going to happen.
Forget about it. They are not your bug reports and anyone is
actually /welcome/ to improve them. Get used to it.
To get technical on the improvement bit, we have agreed time on time
that stating the atom and then the action is the way to go. The main
reasons is that it helps people who need to regularly read /lists/ of
bug summaries sort them better. Until we get a specific [Atoms] field
implemented, it will need to stay this way.
Besides the finer technical points of bug maintenance, it simply
infuriates me that anyone would think of bug reports in the possessive.
This is not the way to improve the distro. You're on the wrong track
there. And you weren't being friendly.
No kind regards to the sender,
jer
Re: [gentoo-dev] Response to a friendly note about changing bug reports
Am Dienstag, 6. August 2013, 23:46:08 schrieb Jeroen Roovers:
23:37:25 willikins rej, you have notes! [21:13] mrueg Let me
rephrase this: Just a friendly notice to please refrain from rephrasing
bug summaries from Stabilize ${P} to ${P} stable req. This just
adds unneeded noise to the bug. I don't want this on bugs I've reported
or am assigned to.
This is my equally short and friendly note: It's not going to happen.
Forget about it. They are not your bug reports and anyone is
actually /welcome/ to improve them. Get used to it.
To get technical on the improvement bit, we have agreed time on time
that stating the atom and then the action is the way to go. The main
reasons is that it helps people who need to regularly read /lists/ of
bug summaries sort them better. Until we get a specific [Atoms] field
implemented, it will need to stay this way.
Jer,
please stop making whitespace noise on bugs that you have absolutely no
relation to. It just causes unnecessary bugmail. If maintainers care they will
change it themselves.
Cheers,
Andreas
--
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfri...@gentoo.org
http://www.akhuettel.de/
[gentoo-dev] Re: renaming gentoo-oldnet
Ian Stakenvicius posted on Tue, 06 Aug 2013 10:47:05 -0400 as excerpted: Or alternatively, rc-net ? (google seems to reference 'rc' as 'remote control' as in race cars, airplanes, etc; but given /etc/rc.* and /etc/init* have been around forever and have always been called the rc system, i think we should be safe using it) Hmm... sounds like something the NSA could love if there's ever a remotely exploitable vuln. Remote-control-net indeed! =:^( Never-the less, it's still reasonable even if I like the net-rc idea better. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
