Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
I'm a bit surprised about this discussion as Mike, who currently maintains the toolchain, has never implied that suddenly older versions of glibc are unusable. Or that we need a big cleanup. He simply stated two facts (that have been true for a long time) - for a current kernel a current toolchain is necessary and vice versa. - we support older versions of glibc (gcc/etc.) mainly for crossdev (and some other special purposes) on a best effort basis without any usability or security guarantees. The latter implies that you should not actively use them in your regular Gentoo setup, not that they must be removed from the tree. [...] Crossdev was mentioned in discussions on irc, but again it wasn't clear to me why specific versions of glibc are needed. I don't know of any hard dependencies in the portage tree like that. Again, just the simple fact that crossdev without the ability to select specific versions of glibc is only half as useful. And please, do not underestimate the usefulness of our crossdev script in this regard! Because you're arguing that no example was presented: E.g. I've an embedded armv7a-hardfloat board which ships with glibc 2.16 (This is a concrete example and not a vague some users might need it.). I want to have a cross compile environment for it to compile some specific software (not a complete userland). I do not want to replace the userland/ship a custom sysroot/use an LD_LIBRARY_PATH hack, so I'm basically forced to compile with a glibc of at most 2.16 (otherwise you get symbol lookup errors.) To ease the maintenance burden there are multiple possibilities to tackle it without removing old glibc versions altogether: - We could debundle newer glibc versions from toolchain.eclass/eblits - We could migrate older versions in a dedicated overlay with some sort of versioned toolchain.eclass/eblits. (same for the other canonical packages). Further, if the fact that specific versions are unmaintained (and do not get any security backports) it is also possible to just drop keywords. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On Mon, Dec 22, 2014 at 11:55 PM, William Hubbs willi...@gentoo.org wrote: Because of that, i see no reason to keep the older versions of glibc around. This would also give us a chance to clean up the ebuilds without causing massive breakage. the eblits need to die. Who is actually maintaining glibc, and what ebuilds do THEY want to keep around? I'm not sure why this needs a big community decision around cleaning them out. They can keep around 10-year-old versions of glibc as far as I'm concerned, as long as they promptly address bugs that are blockers for other packages. If they don't, then I'm all for unblocking those other packages (ie the maintainers of the other packages can ignore old glibc bugs and proceed to break systems that use those versions). So, nobody is forcing the glibc maintainers to do anything, but neither are the glibc maintainers forcing anybody else to do anything to support stuff more than a year old. -- Rich
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On 12/22/14 16:37, Andreas K. Huettel wrote: Am Montag, 22. Dezember 2014, 18:24:32 schrieb Anthony G. Basile: Well the side effect of this is that arcane and unmaintainable bandworms like toolchain.eclass are generated, with dozens of case distinctions for packages that *nearly* noone needs. Yes it's fine to keep old things for a few people, does it merit slowing everyone else down though? Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3, 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3, 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20? I can't fully speak to this as I'm not familiar. But are you? No, I'm not. Which is why I am asking. I'm happy to learn. Shall I google that for you? j/k Here are the change logs - http://www.gnu.org/software/libc/ There are always some big ticket items like I remember when -lrt stuff was moved into glibc or further back when resolver stuff was moved out. Each of these changes usually means breakage usually in terms of what breakout libraries you need and what linker flags you need. But I can't pretend to have watched it closely like I'm sure Mike does. I've watched musl and uclibc and just hit up against the glibc changes as they mysteriously rain down from Drepper. (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2, 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2? Between 4.8.3 and 4.8.4 there were 80 bug fixes with a yet unknown number of regressions. Most people that hit these kinds of problems revert to the previous working versions. OK, so then let's keep all 4.7.x, 4.8.x, 4.9.x, the latest stable 4.5 and 4.6, and maybe 3.4. And how would someone running 4.9 get to 3.4? I tested on amd64 and I can compile any version of gcc in the tree with 4.8, except 2.95 which I can't compile with *any* version. But that's on *amd64* I did not test on the other arches. It would be bad if we did this and then 3.4 is not buildable from4.8 but is from some intermediate version which we dumped. The general testing rule for compiling gcc with gcc is two versions back/forwards --- Ryan can correct me if he was doing something different, but thats' what I've done for ages. So you really need to keep that chain 4.8 - 4.7 - 4.6 ... - 3.3 going. Add to that the quantum leaps between 4.X and 4.(X+1) with no backwards compat in abis. Plus the fact that some sensitive software usually aimed a special chips need specific versions and the answer is ... yes. One of the many moments when I really wish we had gentoostats up and running. Why not let the maintainer decide what he/she will maintain? State exactly is broken with toolchain that needs fixing and let's fix it. But fixing it because its aesthetically unpleasing isn't good engineering. Like the messy drawer in the kitchen. Every other drawer is nice and tidy and you marvel at its organizational beauty. So you stuff all the ugly complexity in this one drawer. No matter how much you try to organize that drawer, its stays messy. And here's the thing. Its useful that way. You can't get your brain around all the mess and so you obsess about cleaning it up but if you give into the temptation, the next time you need that square ladle you dumped because it was ugly you'll regret it. Is it possible to emerge @system with, say, e.g. gcc-4.0 or 4.1? From the discussions about hardened 3.x is still interesting. But how much can you still do with it, does anyone try regularly? Is anyone even testing 2.95 anymore? What happened here (in part) is the way we're doing multilib is percolating through gentoo and hitting things it doesn't mesh with well. That's fine we have to glue things together correctly. Throwing stuff away when it doesn't mesh is not fine when its something good. Please explain the specific connection of this problem with multilib. (Shouldn't you usually use the same gcc version for your whole system as far as you can?) Better yet, look at mgorny's ebuild approach to gcc-4.9 and you'll see the inclusion of multilib. We want that for things like 64-bit address space in gcc for mips - https://bugs.gentoo.org/show_bug.cgi?id=477956 Build sys-devel/gcc as an N64 binary on MIPS profiles with non-N64 default ABI -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On 12/22/14 23:55, William Hubbs wrote: All, this discussion got side-tracked into gcc, which was not my intent; let's go back to my specific question about glibc. On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote: some of such software is binary, some other is too large to be updated regularly. Please give REASONS why things should remain maintained. So far (except for the gcc-3/hardened explanations, and for gcc-3 doing more fortran than gcc-4(??)) this is mostly mumbo-jumbo about someone might need it, proprietary binary blobs (should we even care? if yes, why?) and similar. I vote that we shouldn't care about proprietary binary blobs. Oh dear god this is going from bad to worse. I love blobs as much as the next person but there are people that need this stuff if gentoo is to be useful for them. Let's not care about blobs and shut down linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II which need blobs. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On Tue, Dec 23, 2014 at 08:45:49AM -0500, Anthony G. Basile wrote: On 12/22/14 23:55, William Hubbs wrote: All, this discussion got side-tracked into gcc, which was not my intent; let's go back to my specific question about glibc. On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote: some of such software is binary, some other is too large to be updated regularly. Please give REASONS why things should remain maintained. So far (except for the gcc-3/hardened explanations, and for gcc-3 doing more fortran than gcc-4(??)) this is mostly mumbo-jumbo about someone might need it, proprietary binary blobs (should we even care? if yes, why?) and similar. I vote that we shouldn't care about proprietary binary blobs. Oh dear god this is going from bad to worse. I love blobs as much as the next person but there are people that need this stuff if gentoo is to be useful for them. Let's not care about blobs and shut down linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II which need blobs. I have never heard him say that keeping old software in the tree is necessary for the blobs he uses. If that is the case, that is something that must be considered. I was just echoing the current policy about blobs; they are not a reason to block stabilization of other packages etc. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On 12/23/14 09:39, William Hubbs wrote: On Tue, Dec 23, 2014 at 08:45:49AM -0500, Anthony G. Basile wrote: On 12/22/14 23:55, William Hubbs wrote: All, this discussion got side-tracked into gcc, which was not my intent; let's go back to my specific question about glibc. On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote: some of such software is binary, some other is too large to be updated regularly. Please give REASONS why things should remain maintained. So far (except for the gcc-3/hardened explanations, and for gcc-3 doing more fortran than gcc-4(??)) this is mostly mumbo-jumbo about someone might need it, proprietary binary blobs (should we even care? if yes, why?) and similar. I vote that we shouldn't care about proprietary binary blobs. Oh dear god this is going from bad to worse. I love blobs as much as the next person but there are people that need this stuff if gentoo is to be useful for them. Let's not care about blobs and shut down linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II which need blobs. I have never heard him say that keeping old software in the tree is necessary for the blobs he uses. If that is the case, that is something that must be considered. I was just echoing the current policy about blobs; they are not a reason to block stabilization of other packages etc. William That's not what you said. I was responding to I vote that we shouldn't care about proprietary binary blobs not to I have never heard him say that keeping old software in the tree ... I test for him on his equipment and there you must care about proprietary blobs. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On Tue, Dec 23, 2014 at 09:10:32AM +0100, Matthias Maier wrote: I'm a bit surprised about this discussion as Mike, who currently maintains the toolchain, has never implied that suddenly older versions of glibc are unusable. Or that we need a big cleanup. He simply stated two facts (that have been true for a long time) - for a current kernel a current toolchain is necessary and vice versa. - we support older versions of glibc (gcc/etc.) mainly for crossdev (and some other special purposes) on a best effort basis without any usability or security guarantees. The latter implies that you should not actively use them in your regular Gentoo setup, not that they must be removed from the tree. I cc'd Mike on my original message in this thread specifically because I hoped he would see it and tell me if I was wrong to start discussing a cleanup, because I read part of his message as implying that a cleanup might be coming. Specifically, he also said that if you were stuck on old stuff you should start unsticking your stuff. just the simple fact that crossdev without the ability to select specific versions of glibc is only half as useful. And please, do not underestimate the usefulness of our crossdev script in this regard! I'm not saying anything about breaking the crossdev script by making it unable to select specific versions of glibc. Because you're arguing that no example was presented: E.g. I've an embedded armv7a-hardfloat board which ships with glibc 2.16 (This is a concrete example and not a vague some users might need it.). I want to have a cross compile environment for it to compile some specific software (not a complete userland). I do not want to replace the userland/ship a custom sysroot/use an LD_LIBRARY_PATH hack, so I'm basically forced to compile with a glibc of at most 2.16 (otherwise you get symbol lookup errors.) Ok, this is something to consider then. 2.16 is not all that old, so keeping it around for a while longer isn't a big deal. To ease the maintenance burden there are multiple possibilities to tackle it without removing old glibc versions altogether: - We could debundle newer glibc versions from toolchain.eclass/eblits I don't see toolchain.eclass being inherited in the glibc ebuilds; it is just eblits. Honestly I wouldn't have a problem with seeing them die in all versions of the ebuilds if we can make that happen. - We could migrate older versions in a dedicated overlay with some sort of versioned toolchain.eclass/eblits. (same for the other canonical packages). It looks like there already is a toolchain overlay that might have this, check git.overlays.gentoo.org. Further, if the fact that specific versions are unmaintained (and do not get any security backports) it is also possible to just drop keywords. (qa hat on for this statement only) as a qa member, my opinion on this is, if something has a serious security issue which the maintainer knows is not going to be fixed, it doesn't belong in the main tree. signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On Tue, Dec 23, 2014 at 09:46:28AM -0500, Anthony G. Basile wrote: On 12/23/14 09:39, William Hubbs wrote: On Tue, Dec 23, 2014 at 08:45:49AM -0500, Anthony G. Basile wrote: On 12/22/14 23:55, William Hubbs wrote: All, this discussion got side-tracked into gcc, which was not my intent; let's go back to my specific question about glibc. On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote: some of such software is binary, some other is too large to be updated regularly. Please give REASONS why things should remain maintained. So far (except for the gcc-3/hardened explanations, and for gcc-3 doing more fortran than gcc-4(??)) this is mostly mumbo-jumbo about someone might need it, proprietary binary blobs (should we even care? if yes, why?) and similar. I vote that we shouldn't care about proprietary binary blobs. Oh dear god this is going from bad to worse. I love blobs as much as the next person but there are people that need this stuff if gentoo is to be useful for them. Let's not care about blobs and shut down linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II which need blobs. I have never heard him say that keeping old software in the tree is necessary for the blobs he uses. If that is the case, that is something that must be considered. I was just echoing the current policy about blobs; they are not a reason to block stabilization of other packages etc. William That's not what you said. I was responding to I vote that we shouldn't care about proprietary binary blobs not to I have never heard him say that keeping old software in the tree ... I test for him on his equipment and there you must care about proprietary blobs. Sure, but I was just saying that Gentoo policy doesn't currently care about proprietary blobs. Specifically, I don't think a proprietary blob or the breakage of one can be used as a reason to block stabilization of a new version of a package or removal of an old version of the package wrt the main tree. That's my understanding of our policy; however, as usual, I am open to being corrected. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
Am 23. Dec 2014, 16:51 schrieb William Hubbs willi...@gentoo.org: just the simple fact that crossdev without the ability to select specific versions of glibc is only half as useful. And please, do not underestimate the usefulness of our crossdev script in this regard! I'm not saying anything about breaking the crossdev script by making it unable to select specific versions of glibc. Then, we have to provide the ebuilds for those versions somehow. Ok, this is something to consider then. 2.16 is not all that old, so keeping it around for a while longer isn't a big deal. Same goes for any other arbitrary version in the course of the last 4 years :-) - We could migrate older versions in a dedicated overlay with some sort of versioned toolchain.eclass/eblits. (same for the other canonical packages). It looks like there already is a toolchain overlay that might have this, check git.overlays.gentoo.org. I had a closer look at it and it turns out it is Mike's development and 'ebuild retirement' overlay. He already maintains some older versions in this overlay. So, in conclusion, why not just asking him to just move older glibc versions back to the toolchain overlay as soon as they become unmaintained (i.e. without security backports)? Best, Matthias signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-misc/fixdos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (23 Dec 2014) # Homepage returns 404 which probably suggests upstream has vanished. # Superseded by app-text/dos2unix. Bug #533222 app-misc/fixdos - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUmcxQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZRr0H/iYLi80GraQ9QoHujNJcl7hq 7jdNdAXuHfOgnNUgHAhIAoAeBEEjjQgTbzbtHYv7HiSzBoi3ygpKMnuNzUWI8x3L uRMZU404JHWHOcBFYQ8zcoiVyc16kLewBvIYArYQ+mB87kkLNAElDPszE18N4I9f rojetCbMGyN52WyxPrYY+n572snca+rU8ZlKFw+i96DGcK/kS6KTXNCJKjb8qEeH 6Nuj4K2n2aUHpswag4em1ennDsV96kfSQ1FNpjL/u3B7/m614JrKq6Pt9NGqNvnw 6ptmqK0crQJxqdsG/U7WxF9AFmqIfR1D0ZNJRo4y60S3yU+Fw7a1aAmYCF+p9QU= =SBs6 -END PGP SIGNATURE-
[gentoo-dev] git.gentoo.org/git.overlays.gentoo.org upgrades, 2014/12/24 2014/12/26
Hi all, I'm going to be doing some upgrades of Gitolite on our Git services, it'll be split between Dec 24th and Dec 26th. Watch #gentoo-dev IRC topic for a more live report of times, but I expect the outage portions to be under 45 minutes collectively. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 signature.asc Description: Digital signature
[gentoo-dev] Re: rfc: glibc versions prior to 2.19-r1
Anthony G. Basile posted on Tue, 23 Dec 2014 08:36:44 -0500 as excerpted: I've watched musl and uclibc and just hit up against the glibc changes as they mysteriously rain down from Drepper. Just a quick reply to this side point... There's no indication in your post that you're aware that Drepper is out of the glibc picture, now. He is, and has been for... I think at least a year, now. You could of course google it if you're interested in the details, but he has definitely moved on to other things, now, and is no longer glibc controlling god, or even, AFAIK, still involved in glibc at all. (I've seen no need to get involved in the general thread...) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
On Tue, Dec 23, 2014 at 5:36 AM, Anthony G. Basile bluen...@gentoo.org wrote: On 12/22/14 16:37, Andreas K. Huettel wrote: Am Montag, 22. Dezember 2014, 18:24:32 schrieb Anthony G. Basile: Well the side effect of this is that arcane and unmaintainable bandworms like toolchain.eclass are generated, with dozens of case distinctions for packages that *nearly* noone needs. Yes it's fine to keep old things for a few people, does it merit slowing everyone else down though? Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3, 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3, 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20? I can't fully speak to this as I'm not familiar. But are you? No, I'm not. Which is why I am asking. I'm happy to learn. Shall I google that for you? j/k Here are the change logs - http://www.gnu.org/software/libc/ There are always some big ticket items like I remember when -lrt stuff was moved into glibc or further back when resolver stuff was moved out. Each of these changes usually means breakage usually in terms of what breakout libraries you need and what linker flags you need. But I can't pretend to have watched it closely like I'm sure Mike does. I've watched musl and uclibc and just hit up against the glibc changes as they mysteriously rain down from Drepper. Sorry, what would he be Googling? He asked why we needed all of the various old versions, not why new versions keep coming out. Also, Drepper hasn't been involved with glibc development in two and a half years.
[gentoo-portage-dev] [PATCH] emerge: add --changed-deps/--binpkg-changed-deps (282927)
The @changed-deps set is useful, but it has limitations similar to the
@installed set (see bug #387059), which can make it unsuitable for use
when updating the whole system. Therefore, implement two new options
that are analogous to --newuse and --binpkg-respect-use, called
--changed-deps and --binpkg-changed-deps.
The rationale for having a separate --binpkg-* option is the same in
both cases: depending on the situation, people may want different
behavior for binary packages. For example, just like
---binpkg-respect-use is automatically enabled if the user has not
specified --usepkgonly, so is --binpkg-changed-deps (though the user
can explicitly override the automatic behavior). In both cases,
inconsistencies in dependencies are automatically avoided, increasing
the probability of a successful dependency calculation.
X-Gentoo-Bug: 282927
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=282927
---
man/emerge.1| 22 +++-
pym/_emerge/create_depgraph_params.py | 16 +++
pym/_emerge/depgraph.py | 138 ++--
pym/_emerge/main.py | 26 +
pym/portage/dep/_slot_operator.py | 13 +++
pym/portage/tests/resolver/test_changed_deps.py | 120 +
6 files changed, 323 insertions(+), 12 deletions(-)
create mode 100644 pym/portage/tests/resolver/test_changed_deps.py
diff --git a/man/emerge.1 b/man/emerge.1
index faa1f33..7eb30a5 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -386,9 +386,20 @@ Specifies an integer number of times to backtrack if
dependency calculation fails due to a conflict or an
unsatisfied dependency (default: \'10\').
.TP
+.BR \-\-binpkg\-changed\-deps [ y | n ]
+Tells emerge to ignore binary packages for which the corresponding
+ebuild dependencies have changed since the packages were built.
+In order to help avoid issues with resolving inconsistent dependencies,
+this option is automatically enabled unless the \fB\-\-usepkgonly\fR
+option is enabled. Behavior with respect to changed build\-time
+dependencies is controlled by the \fB\-\-with\-bdeps\fR option.
+.TP
.BR \-\-binpkg\-respect\-use [ y | n ]
-Tells emerge to ignore binary packages if their use flags
-don't match the current configuration. (default: \'n\')
+Tells emerge to ignore binary packages if their USE flags
+don't match the current configuration. In order to help avoid issues
+with resolving inconsistent USE flag settings, this option is
+automatically enabled unless the \fB\-\-usepkgonly\fR option
+is enabled.
.TP
.BR \-\-buildpkg [ y | n ] (\-b short option)
Tells emerge to build binary packages for all ebuilds processed in
@@ -410,6 +421,13 @@ Creates binary packages for all ebuilds processed without
actually
merging the packages. This comes with the caveat that all build-time
dependencies must already be emerged on the system.
.TP
+.BR \-\-changed\-deps [ y | n ]
+Tells emerge to replace installed packages for which the corresponding
+ebuild dependencies have changed since the packages were built. This
+option also implies the \fB\-\-selective\fR option. Behavior with
+respect to changed build\-time dependencies is controlled by the
+\fB\-\-with\-bdeps\fR option.
+.TP
.BR \-\-changed\-use (\fB\-U\fR)
Tells emerge to include installed packages where USE flags have
changed since installation. This option also implies the
diff --git a/pym/_emerge/create_depgraph_params.py
b/pym/_emerge/create_depgraph_params.py
index 6f74de7..11e20f4 100644
--- a/pym/_emerge/create_depgraph_params.py
+++ b/pym/_emerge/create_depgraph_params.py
@@ -22,6 +22,8 @@ def create_depgraph_params(myopts, myaction):
# ignore_built_slot_operator_deps: ignore the slot/sub-slot := operator
parts
# of dependencies that have been recorded when packages where
built
# with_test_deps: pull in test deps for packages matched by arguments
+ # changed_deps: rebuild installed packages with outdated deps
+ # binpkg_changed_deps: reject binary packages with outdated deps
myparams = {recurse : True}
bdeps = myopts.get(--with-bdeps)
@@ -51,6 +53,7 @@ def create_depgraph_params(myopts, myaction):
--newuse in myopts or \
--reinstall in myopts or \
--noreplace in myopts or \
+ myopts.get(--changed-deps, n) != n or \
myopts.get(--selective, n) != n:
myparams[selective] = True
@@ -99,6 +102,19 @@ def create_depgraph_params(myopts, myaction):
# have been specified.
myparams['binpkg_respect_use'] = 'auto'
+ binpkg_changed_deps = myopts.get('--binpkg-changed-deps')
+ if binpkg_changed_deps is not None:
+ myparams['binpkg_changed_deps'] = binpkg_changed_deps
+ elif '--usepkgonly' not in myopts:
+ # In order to avoid dependency resolution issues due to changed
+
[gentoo-portage-dev] [RFC] New file layout for PKGDIR and binhosts
Hi,
As discussed in bug 150031 [1], it would be useful if PKGDIR could
accommodate multiple binary packages built from the same source ebuild.
Use cases for preserving multiple builds typically involve supporting
multiple clients (with partially compatible configurations) from a
single unified binhost. In this context, some of the reasons to retain
multiple builds are:
* Different USE flag combinations enabled (--newuse/--binpkg-respect-use
needed)
* Different versions of installed dependencies (EAPI 5 slot := operators
needed)
* Different repositories/overlays, with variance in the time of the last
sync (--changed-deps/--binpkg-changed-deps needed if dependencies change
due to eclass changes or ebuild modifications without revbump)
Given the above variety of reasons to retain previous builds, a simple
counter (1, 2, 3,...) seems like a reasonable means to generate unique
file names.
In order to avoid having too many files in a directory, we can use a
separate directory for each ${CATEGORY}/${PN}, like we do for the source
ebuild repositories.
In order to avoid having to deal with multiple file extensions for
different compression types, we can simply use .xpak for the file
extension [2], since that's the name of the format that we use to append
metadata to our existing tbz2 files. We can simply probe the first few
bytes of the file in order to determine the compression type:
gzip: 1f 8b
bzip2: 42 5a 68 39
xz: fd 37 7a 58 5a 00
Users will be able change their compression settings at any time, but
the .xpak file extension will remain constant regardless of that
setting. It won't matter if they have a mixture of files compressed with
different compressors.
A tool like eclean-pkg will be needed to clean up old binary packages
based on user preferences. We might also provide a variety of on-the-fly
garbage collection settings.
Based on the above discussion, the location of any particular binary
package can be expressed as follows:
${PKGDIR}/${CATEGORY}/${PN}/${PF}-${COUNTER}.xpak
The existing format of the ${PKGDIR}/Packages index will work fine,
since it allows each package to specify a PATH attribute which
corresponds to the path of the file relative to the base directory. If
the .xpak files use bzip2 compression, it will even be compatible with
existing clients (though they won't be able to intelligently choose
between multiple packages of the same version). If all the packages of a
given version are ordered by ${COUNTER}, then existing clients will
simply download the latest build.
[1] https://bugs.gentoo.org/show_bug.cgi?id=150031
[2] http://dev.gentoo.org/~zmedico/portage/doc/man/xpak.5.html
--
Thanks,
Zac
