[OT] Re: [gentoo-dev] minimalistic emerge
On Sat, 9 Aug 2014 19:25:56 +0400 Igor lanthrus...@gmail.com wrote: In my experience - hacking into 96 system with a 0 door is much harder than in 2014. In most cases unless you're an expert on 96 software which is difficult nowadays due to human memory. Why does one need to be an expert? How about known and/or implemented exploits? To really break in you need to reproduce server environment as close as possible or/and have a clear understanding how this particular software works. Try to assemble a 96 system on modern hardware or assemble it as they were back in 96, not all sources are online any longer, that is a hard job. 2014 systems are much easier to assemble and get a peek to the sources is a trifle. Why reproduce the environment? Is the sources' availability the only factor? As Linux software is open-source it's often easier to break in Linux than in Windows systems. The open source is only theoretically safer. Many belive that because the code is open - it's reviewed and checked and the number of critical bugs is low. But the reality is that there is usually no time to review code. Many modern software is very complex with millions lines and it's not realistic to check or understand how it works before you use it in your project. Tell me how many libraries that you use right now are reviewed by you personally? Not many. And that is a door that is NEVER going to be closed. There are bugs, rest assured, if you pull any soft right now and spend time you will find them. If you have an expertise on cross platforms - you will find even more as developers used to focus on one platform the birth platform. Can you back up that open source is theoretically safer / harder / ...? It depends on how you look at the source code and binaries; having either doesn't necessarily make it easier or harder to accomplish, especially if you want to find run-time behavior to exploit. You could scan through the source code looking for known errors or so; however, the same is possible to do with the machine code. Both can be done manually or automatically; whether it gets tedious to find, depends on what it is exactly that you are trying to find and how you find it. If you compare the number of bugs you find in 1996 software and in 2014 - the numbers would approximately be the same. That reads like a wild guess due to too much assumptions / conditionals. Usually 1996 system is patched or protected against known issues and you have to deal with unknown which in case of 1996 is much harder. This also reads like a wild guess; words ending in -ly like usually indicate that you're not sure about it and how much of it really is as such, a more believable statement would read like ...% of the systems in 1996 are ... [reference to research]. Another weak link with open source is software developers. Many of them spend a lot of time on their software not always getting a fair monetary reward. So if you a very shrewd and have resources - you go to developers and offer them money to introduce a subtle bug into the main tree. After the software is adopted then you have open doors in EVERY updated linux on the planet. Personally I belive Heart Bleed bug is one of such. You can never proof if the bug is artificial or not - how? The same true for Microsoft soft. You can basically go to a ntkernel developer offer him 500 000$ if have them and he would add a bug and explain you how to use it and you're everywhere :-) but this is usually the government's methods. They used to keep them secret. Have you considered steady high incomes and the aftermath? With a steady high income and a high level job as Microsoft kernel developer, 500 000$ and the aftermath of consequences loses traction. You might be able to convince that single kernel developer; however, that developer still has to slip this by the rest of the kernel development team as well as quality assurance processes and measures. Getting by the static and dynamic analyzers as well as other run-time measures they have to their availability for awareness is harder than without it; apart from it, there's are also human code reviews and QA. The story gets somewhat different when people don't end up using them, or not spend an equivalent effort; like for example with Heart Bleed. Think about some random unrelated pieces of open source libraries; did that get run through analyzers and include run-time measures, have code reviews like kernels would have and extended QA procedures? https://i.imgflip.com/b3mx0.jpg -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Fri, 8 Aug 2014 15:32:37 +0200 Jeroen Roovers j...@gentoo.org wrote: Nice capitalisation! Speaking of which, where is the US$ 1,000,000 (ONE MILLION UNITED STATES DOLLARS) you promised in your last e-mail? Nice placement of the space behind the dollar sign! No money for you. Don't bother to file bug reports if you think a fully up to date system is not for you. Where do we state to have a fully up-to-date system before filing a bug? This in particular becomes interesting to do when the bug keeps you from updating your system; or even further, rendering it non bootable. We need to fix things such that people have a working system that they can bring up-to-date; not the other way around, as that is pointless. Automatic updates is a goal to pursue; well, at least if you want everyone to have a fully up-to-date bootable system that can update. Is there any option in emerge to pull MINIMUM packages to get the result - install the application you need, leaving everything else AS IS untouched and stable? RTFM. Why do you point to a manual which does not document such feature? If no such USE flag, what about stabilize gentoo with STABILIZED flag implementation in make.conf? Next time, please bother the gentoo-user@ mailing list. No. The gentoo-user@ ML can't do anything about a missing feature. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Sat, 9 Aug 2014 18:10:51 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 09 Aug 2014 11:12:46 -0400 Chris Reffett creff...@gentoo.org wrote: Then write it. Portage's source is available to anyone. It's quicker to start from scratch than to try to add things to Portage's source... But do we want to be quicker? If you want a lot of input, Portage... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Fri, 08 Aug 2014 23:04:40 +0200 Johannes Huber j...@gentoo.org wrote: /me is thinking: Your caps lock key is broken and about the content: man portage || use linux from scratch Caps lock highlighting is a common practice. Why do you tell him to read a manual or use a distribution that both lack the requested feature? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
Tom Wijsman: On Sat, 9 Aug 2014 18:10:51 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 09 Aug 2014 11:12:46 -0400 Chris Reffett creff...@gentoo.org wrote: Then write it. Portage's source is available to anyone. It's quicker to start from scratch than to try to add things to Portage's source... But do we want to be quicker? If you want a lot of input, Portage... How is your private PM project going? I heard you want to write a PM from scratch in C++.
Re: [gentoo-dev] minimalistic emerge
Rich Freeman wrote: If upstream happens to say it requires foo-1.5, by all means just take their word for it and list it, Don't take their documentation's word for it however, but look at what the build actually requires. (E.g. configure.ac.) //Peter
Re: [gentoo-dev] minimalistic emerge
On 8/8/14, 6:27 PM, Igor wrote: Is there any warranty that updated with -uDN system will remain full functional for 1 year? I have 100% warranty that not updated system is going to remain functional for 5 or 6 years. I have some with 7 years uptime. I'd say there is no warranty. However, a staging environment can help detecting issues earlier, before deploying them to production and allowing you to come up with a way to address them. I certainly wouldn't recommend just running an update on a running production server without testing it first. I'm in a trap - if I update daily - the systems are offline, I'm not able to maintain systems after updates - requires too much resources. If you have 1 gentoo it might take a few days, imagine you have 100 or 1000 systems and they do not share the same hardware or the same boot locations, they all can be managed by 2 people if not updated and you need about 100 people if you update. Consider automating the processes - as you pointed out, the way described above doesn't scale. Possibly relevant article would be http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html The number of bugs is the same. It's more difficult to hack into 1996 system than in 2012. Do you have any evidence to back that claim? There are tons of known vulnerabilities in '96-era software, and automated exploits for them. By the way, I can see a point in your thread. Our updates and package manager could be improved. They have improved greatly in the last few years. I think I can safely say we welcome further contributions of patches, packaging and testing effort, especially helping automate many of these tasks. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] minimalistic emerge
Hello Kent, Saturday, August 9, 2014, 1:33:30 AM, you wrote: Yes. As I said, INSTALLATION metrics reporting is easy enough to do. I use those sorts of tools EXTENSIVELY with the CPAN platform, and I have valuable reports on what failed, what the interacting components were, and what systems the failures and passes occur on. So I greatly appreciate this utility. Automated bug reports however prove to be a waste of time, a lot of failures are in fact entirely spurious as a result of user error. So a metrics system that simply aggregates automated reports from end users that is observed as a side channel to bugs, proves more beneficial in reality. Usually all maintainers need here is a daily or even weekly digest mail summarising all the packages they're involved with, with their failure summaries, with links to the failures. ( For example, here is one of the report digests I received: http://i.imgur.com/WISqv15.png , and one of the reports it links to : http://www.cpantesters.org/cpan/report/ed7a4d9f-6bf3-1014-93f0-e557a945bbef ) It's exactly what I think is missing with portage. Yes, CPAN was always reliable. Feedback stands for adaptation. Another thing to learn from PERL is command line bug reporting tool that reports bugs directly on their bug tracking website. A great tool, usually with Gentoo you go to support then you post emerge environment and answer questions which a reporting module launched locally knows better than you. That drives a lot of time out of bag tracking team - they always have to ask the same questions reporters miss. And for such, you don't need to apply rate limiting, because multiple reports from a single individual prove to be entirely inconsequential, as you're not forced to deal with them like normal bugs, but are simply out of band feedback you can read when you have the time. And you can then make sense of the content of that report using your inside expertise and potentially file a relevant bug report based on extracted information, or use context of that bug report to request more context from its submitter. But the point remains that this techology is _ONLY_ effective for install time metrics, and is utterly useless for tracking any kinds of failures that emanate from the *USE* of software. True because what we address is portage stabilization, not the system. But portage hell accounts (my esteem) for about 80% of all Gentoo user problems. The system stabilization after updates could be improved if there is way to minimize dependencies i.e. - not to pull updates unless necessary for the target assembly. In a long perspective - there might be ways to asses what happened after update on function level. For example if daemon didn't start after update - it's a clear indication that there is a problem at least with the backward compatibility. When an administrator troubleshoots system he follows an algorithm a pattern, it's a complex pattern but it could be programmed to some extent. If my firefox installation segv's, nothing is there watching for that to file a report. If firefox does something odd like renders characters incorrectly due to some bug in GPU drivers ( actual issue I had once ), nothing will be capable of detecting and reporting that. Could be done but the effort is unreasonable. Those things are still bugs and are still bugs in packages and still bugs in packages that can be resolved by changing dependencies, but are however completely impossible to test for in advance of them happening as part of the installation toolchain. But I'm still very much on board with have the statistics system. I use it extensively, as I've said, and it is very much one of the best tools I have for solving problems. ( the very distribution of the problems can itself be used to isolate bugs. For instance, http://matrix.cpantesters.org/?dist=Color-Swatch-ASE-Reader%200.001000 Very nice! Those red lights told me that I had a bug on platforms where perl floating point precision is reduced In fact, *automated* factor analysis pin pointed the probable cause faster than I ever could: http://analysis.cpantesters.org/solved?distv=Color-Swatch-ASE-Reader-0.001000 Great, once the stats are there, with growing experience new tools could be written to automatically analyze data and make decisions. Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't
Re: [gentoo-dev] minimalistic emerge
Hello Paweł, Saturday, August 9, 2014, 1:34:29 PM, you wrote: Possibly relevant article would be http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html The number of bugs is the same. It's more difficult to hack into 1996 system than in 2012. Do you have any evidence to back that claim? There are tons of known vulnerabilities in '96-era software, and automated exploits for them. By the way, I can see a point in your thread. Our updates and package manager could be improved. They have improved greatly in the last few years. I think I can safely say we welcome further contributions of patches, packaging and testing effort, especially helping automate many of these tasks. In my experience - hacking into 96 system with a 0 door is much harder than in 2014. In most cases unless you're an expert on 96 software which is difficult nowadays due to human memory. To really break in you need to reproduce server environment as close as possible or/and have a clear understanding how this particular software works. Try to assemble a 96 system on modern hardware or assemble it as they were back in 96, not all sources are online any longer, that is a hard job. 2014 systems are much easier to assemble and get a peek to the sources is a trifle. As Linux software is open-source it's often easier to break in Linux than in Windows systems. The open source is only theoretically safer. Many belive that because the code is open - it's reviewed and checked and the number of critical bugs is low. But the reality is that there is usually no time to review code. Many modern software is very complex with millions lines and it's not realistic to check or understand how it works before you use it in your project. Tell me how many libraries that you use right now are reviewed by you personally? Not many. And that is a door that is NEVER going to be closed. There are bugs, rest assured, if you pull any soft right now and spend time you will find them. If you have an expertise on cross platforms - you will find even more as developers used to focus on one platform the birth platform. If you compare the number of bugs you find in 1996 software and in 2014 - the numbers would approximately be the same. Usually 1996 system is patched or protected against known issues and you have to deal with unknown which in case of 1996 is much harder. Another weak link with open source is software developers. Many of them spend a lot of time on their software not always getting a fair monetary reward. So if you a very shrewd and have resources - you go to developers and offer them money to introduce a subtle bug into the main tree. After the software is adopted then you have open doors in EVERY updated linux on the planet. Personally I belive Heart Bleed bug is one of such. You can never proof if the bug is artificial or not - how? The same true for Microsoft soft. You can basically go to a ntkernel developer offer him 500 000$ if have them and he would add a bug and explain you how to use it and you're everywhere :-) but this is usually the government's methods. They used to keep them secret. -- Best regards, Igormailto:lanthrus...@gmail.com
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote: [snip] Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't see any future of this system unless it's coded in portage. Today - portage support without server side - tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for Portage QOS or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying we should have (some feature) doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote: [snip] Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't see any future of this system unless it's coded in portage. Today - portage support without server side - tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for Portage QOS or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying we should have (some feature) doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote: [snip] Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't see any future of this system unless it's coded in portage. Today - portage support without server side - tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for Portage QOS or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying we should have (some feature) doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 11:46:54 AM EDT, Chris Reffett creff...@gentoo.org wrote: On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote: [snip] Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. IMHO seriously, it could be done if ONLY portage dev team would implement an interface CAPABLE for HTTP reporting. Once the interface is there but turned off by default - server side statistics are feasible. Personally I don't see any future of this system unless it's coded in portage. Today - portage support without server side - tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for Portage QOS or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying we should have (some feature) doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett Apologies for multiple emails getting sent, on a mobile connection here and it reported a failure to send. My bad. Chris Reffett -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] minimalistic emerge
On Sat, 09 Aug 2014 11:12:46 -0400 Chris Reffett creff...@gentoo.org wrote: Then write it. Portage's source is available to anyone. It's quicker to start from scratch than to try to add things to Portage's source... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
On Sat, 09 Aug 2014 11:12:46 -0400 Chris Reffett creff...@gentoo.org wrote: Then write it. I think he's still working on his Portage QOS project. http://article.gmane.org/gmane.linux.gentoo.devel/89472/ jer
[gentoo-dev] minimalistic emerge
Hi, About 60% of all the packages are installed and work with nodep flag without any problems for years. Most of the maintainers just depend on new packages not knowing if it's necessary or not resulting in a really HUGE update that in the absolute majority of cases destabilize GENTOO making it not operational and WORSE than it was before. You then STABILIZE it again spending hours and then the story repeats itself. Experience show that out of 20 new dependencies pulled by emerge only 1 is critical and really needed to assemble the target. Is there any option in emerge to pull MINIMUM packages to get the result - install the application you need, leaving everything else AS IS untouched and stable? I would rather prefer and many would agree to use this kind of install instead of a full system update by default. Is there any USE flag that can switch system to this kind of update instead of conventional? If no such USE flag, what about stabilize gentoo with STABILIZED flag implementation in make.conf? Whoever needs everything new - can continue fighting with nature, the rest of us who has a limited life span - well, they might go for STABILIZED flag and live happily ever after. What do you think? -- Best regards, Igor mailto:lanthrus...@gmail.com
Re: [gentoo-dev] minimalistic emerge
On Fri, 8 Aug 2014 17:12:27 +0400 Igor lanthrus...@gmail.com wrote: Is there any option in emerge to pull MINIMUM packages to get the result - install the application you need, leaving everything else AS IS untouched and stable? cave resolve --lazy :P -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] minimalistic emerge
Igor: Hi, About 60% of all the packages are installed and work with nodep flag without any problems for years. Most of the maintainers just depend on new packages not knowing if it's necessary or not resulting in a really HUGE update that in the absolute majority of cases destabilize GENTOO making it not operational and WORSE than it was before. You then STABILIZE it again spending hours and then the story repeats itself. Experience show that out of 20 new dependencies pulled by emerge only 1 is critical and really needed to assemble the target. Is there any option in emerge to pull MINIMUM packages to get the result - install the application you need, leaving everything else AS IS untouched and stable? I would rather prefer and many would agree to use this kind of install instead of a full system update by default. Is there any USE flag that can switch system to this kind of update instead of conventional? If no such USE flag, what about stabilize gentoo with STABILIZED flag implementation in make.conf? Whoever needs everything new - can continue fighting with nature, the rest of us who has a limited life span - well, they might go for STABILIZED flag and live happily ever after. What do you think? Maybe try paludis. It allows more fine-grained control over the dependency resolution process: http://paludis.exherbo.org/clients/cave-resolve.html
Re: [gentoo-dev] minimalistic emerge
On Fri, 8 Aug 2014 17:12:27 +0400 Igor lanthrus...@gmail.com wrote: About 60% of all the packages are installed and work with nodep flag without any problems for years. Most of the maintainers just depend on new packages not knowing if it's necessary or not resulting in a really HUGE update that in the absolute majority of cases destabilize GENTOO making it not operational and WORSE than it was before. You then STABILIZE it again spending hours and then the story repeats itself. Nice capitalisation! Speaking of which, where is the US$ 1,000,000 (ONE MILLION UNITED STATES DOLLARS) you promised in your last e-mail? Experience show that out of 20 new dependencies pulled by emerge only 1 is critical and really needed to assemble the target. Don't bother to file bug reports if you think a fully up to date system is not for you. Is there any option in emerge to pull MINIMUM packages to get the result - install the application you need, leaving everything else AS IS untouched and stable? RTFM. Is there any USE flag that can switch system to this kind of update instead of conventional? No. You're confusing USE flags with package manager features. If no such USE flag, what about stabilize gentoo with STABILIZED flag implementation in make.conf? Next time, please bother the gentoo-user@ mailing list. jer
Re: [gentoo-dev] minimalistic emerge
On 08/08/2014 15:32, Jeroen Roovers wrote: If no such USE flag, what about stabilize gentoo with STABILIZED flag implementation in make.conf? Next time, please bother the gentoo-user@ mailing list. No, please don't. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] minimalistic emerge
Hello Ciaran, Friday, August 8, 2014, 5:22:03 PM, you wrote: get the result - install the application you need, leaving everything else AS IS untouched and stable? cave resolve --lazy :P A great option name :-) I liked it. Wish it were there. Updating only the minimum necessary packages required is natural, wide system update is a wrong math model. There are regulations in avionics, cybernetics and other life sensitive construction bureaus prohibiting system wide updates. BTW - directly follows from nature. Any complex bird is not updated on daily basis, it takes small steps, small changes targeting only small fixes - natures is adaptive and doesn't know where to move, it probes carefully, always backups, always reversible, moves forward but very accurately, if the change in a bird is deep the chance is that it will stop functioning and die - for nature that means millions of years of genome programming is wasted. Whew, a lot of work. NATURE is VERY lazy, and that's why I liked your option name a lot :-) you nailed it. From Cybernetics: Laziness is a built in algorithm. It controls system resources in case there is no threat to the system purposes with higher priorities. In other words - if what you're doing right now is well adopted to fulfill hard-coded in genome high priority purposes - there IS NO NEED TO CHANGE anything. GENTOO (and many other systems) in many ways violate the profound nature laws found out by venerable scientists, therefore what is done in long perspective is futile, it's more like painting the grass. You need 100 times more effort and resources to keep grass painted, each time you paint - a system wide update happens which is then REVERSED by nature. May be not a good example - but reflecting. One of the main built-in by nature perceptions of what is RIGHT or WRONG in human Genmoe is time. After all our lifes are limited and the most precious what we have is time. Returning to our programming. Anything what is designed by a programmer for a user should be first evaluated from the time users spends. In fact you have no control over it - as a programmer you either accept it or leave the trade. If user feels he spends time - the project is a failure. Anything you ever design - should require no time for a user to achieve the result. And finding and accessing what eats time is the virtue a talented programmer has. Those are problems we face with GENTOO design if only the team could clearly state the problems and shift focus on their solution - GENTOO would be the greatest system ever. BUT From Cybernetics: As the environment changes - most systems are designed to adopt. Meaning there are many alternative systems solving differently same tasks, not VERY differently but differently enough to function in a situation where another system would cease. Many variants of the same system with variations exist in nature. That what keeps is pulling in different directions, we're moving somewhere as most of us are not aware of deep algorithms inside of us which rules us so subtly. The nature is the greatest system designer, we all have to learn from it. PS Jeroen knows an option, but he won't tell - he is from GENTOO bug tracking service - no one can stand bug tracking for more than 1 year and he is there for more than 5, so you reckon.. he is probably reading this right now - try to be very quiet... -- Best regards, Igormailto:lanthrus...@gmail.com
Re: [gentoo-dev] minimalistic emerge
Igor: Hello Ciaran, Friday, August 8, 2014, 5:22:03 PM, you wrote: get the result - install the application you need, leaving everything else AS IS untouched and stable? cave resolve --lazy :P A great option name :-) I liked it. Wish it were there. It is.
Re: [gentoo-dev] minimalistic emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igor - you need to read the emerge man page. emerge -uDNav @world is the recommended way to update your system, because then you will stay in sync with all appropriate updates in the portage tree. However, if you don't want to do this, just emerge -u @world -- that will only update packages in your world file, and will only force dependency updates when the new version is required (based on minimum versions in package dependencies). And if you only want to upgrade things piecemeal, then use --exclude [pkg] to skip updates, or emerge -1 [pkg] to only update an explicit list, or use /etc/portage/package.mask to avoid updating to newer versions. If you're asking for something even lighter than what 'emerge -u @world' will provide, on an automagic system-wide level, then i think you'll need to author some detailed specifications as to exactly what it is you want this new updating feature to do. Please note, though, that we as Gentoo developers can't guarantee that your system is going to remain stable if you don't update --deep, because we can't test every possible combination of every stable-keyworded dependency version against every package -- not even a tinderbox makes that particularly feasible, there's just too many permutations. I also am not sure at this time if 'emerge -u' would upgrade dependencies when the version installed was removed from the portage tree, and this may have multiple adverse effects on your system long-term depending on why that older version was dropped from the tree. So, the recommendation remains that one should update the entire system via -uDN in order to receive all of the updates available for your entire dependency tree. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPk8LQACgkQ2ugaI38ACPA7KAEAgp2dnrl17tsbfWhejRW75/LB Z46UnOotVyIQyoVuQPkA/3AQ4NtBE6R216mtFSwj/8xSetNkKnCx3gBxe6vCJt8T =Eq1Y -END PGP SIGNATURE-
Re: [gentoo-dev] minimalistic emerge
On 9 August 2014 01:12, Igor lanthrus...@gmail.com wrote: Most of the maintainers just depend on new packages not knowing if it's necessary or not resulting in a really HUGE update that in the absolute majority of cases destabilize GENTOO making it not operational and WORSE than it was before. You then STABILIZE it again spending hours and then the story repeats itself. Some of your assumptions seem misguided. Some cases, dependencies are forward specifications from upstream telling us what their software needs to function properly. Failing to meet that requirement could void our support warranty from upstream. Likewise, using 'nodeps' voids your support warranty from gentoo. And just because it works for me that doesn't mean its not broken, it just means you've not encountered the broken scenario that the dependencies exist to guard against. Very often upstream will discover a case where X doesn't work in 10% of the problem space. There's no way to communicate to a user what you will and will not do with the software, so its impossible to know what flaws you will and won't encounter, so the dependencies thus declare a minimum for expected working behaviour for *all* a software's functionality, not just your user-specific subset. If you wish to override that decision, you may, but your self-supporting from that point on. TL;DR = just because it works /for you/, doesn't mean it /isn't broken/ and doesn't mean the minimum declaration is unnecessary for all users. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] minimalistic emerge
Hello hasufell, Friday, August 8, 2014, 7:36:24 PM, you wrote: cave resolve --lazy :P A great option name :-) I liked it. Wish it were there. It is. Thanks! I'll give cave a try. Never used it before. -- Best regards, Igormailto:lanthrus...@gmail.com
Re: [gentoo-dev] minimalistic emerge
Hello Ian, Friday, August 8, 2014, 7:45:56 PM, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igor - you need to read the emerge man page. emerge -uDNav @world is the recommended way to update your system, because then you will stay in sync with all appropriate updates in the portage tree. However, if you don't want to do this, just emerge -u @world -- that will only update packages in your world file, and will only force dependency updates when the new version is required (based on minimum versions in package dependencies). And if you only want to upgrade things piecemeal, then use --exclude [pkg] to skip updates, or emerge -1 [pkg] to only update an explicit list, or use /etc/portage/package.mask to avoid updating to newer versions. It's unreliable, if you update system on daily basis - the system will get unstable and eventually will not even boot. It will be up-to-date but not functional. UDEV was the latest example :-( The updated system requires constant human assistance and the number of CRITICAL bugs is always constant (heart beat bug affected the latest systems but not old). I know no server that is automatically updated with -uDNav @world and works for more than 6 months. I would do it but I know that each time @world updated - I'm in a possible trouble. I need to check all config files, all daemons for changes, boot managers, mdadmin, web servers, mysql, udev, and the surprise will happen when you boot next time. May be in in 300 days, then you try to remember what was changed in 100 days, it's close to a hell. Maintainers - don't have time to test packages against old versions, they just pull in the new versions in e-build with each is doing that and the resulting update is an enormous surplus. If you're asking for something even lighter than what 'emerge -u @world' will provide, on an automagic system-wide level, then i think you'll need to author some detailed specifications as to exactly what it is you want this new updating feature to do. Please note, though, that we as Gentoo developers can't guarantee that your system is going to remain stable if you don't update --deep, because we can't test every possible combination of every stable-keyworded dependency version against every package -- not even a tinderbox makes that particularly feasible, there's just too many permutations. I also am not sure at this time if 'emerge -u' would You need to know what packages are installed and how they're installed world wide. That is the only way to stabilize Gentoo architecture. Firing updates not knowing what happened - is the lack of feedback that is hurting gentoo development. (of course all is IMHO) upgrade dependencies when the version installed was removed from the portage tree, and this may have multiple adverse effects on your system long-term depending on why that older version was dropped from the tree. So, the recommendation remains that one should update the entire system via -uDN in order to receive all of the updates available for your entire dependency tree. Is there any warranty that updated with -uDN system will remain full functional for 1 year? I have 100% warranty that not updated system is going to remain functional for 5 or 6 years. I have some with 7 years uptime. But if I'm going to update a SINGLE package on this system with --emerge it will pull EVERYTHING in, while nodep - may work fine. I'm in a trap - if I update daily - the systems are offline, I'm not able to maintain systems after updates - requires too much resources. If you have 1 gentoo it might take a few days, imagine you have 100 or 1000 systems and they do not share the same hardware or the same boot locations, they all can be managed by 2 people if not updated and you need about 100 people if you update. The number of bugs is the same. It's more difficult to hack into 1996 system than in 2012. I'm very sorry may be I'm not getting it right, it hunts me how it's advisable to update system daily and I'm having a very bad life experience out of advise. May be it's only me? I can't keep a single system functional with auto-updates for just 6 months - something always breaks. For me Gentoo is not a toy, it's a tool I use daily. If a tool is broken - my product is broken. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPk8LQACgkQ2ugaI38ACPA7KAEAgp2dnrl17tsbfWhejRW75/LB Z46UnOotVyIQyoVuQPkA/3AQ4NtBE6R216mtFSwj/8xSetNkKnCx3gBxe6vCJt8T =Eq1Y -END PGP SIGNATURE- -- Best regards, Igormailto:lanthrus...@gmail.com
Re: [gentoo-dev] minimalistic emerge
On Fri, Aug 8, 2014 at 11:45 AM, Ian Stakenvicius a...@gentoo.org wrote: However, if you don't want to do this, just emerge -u @world -- that will only update packages in your world file, and will only force dependency updates when the new version is required (based on minimum versions in package dependencies). I'm not 100% certain, but I believe this will also update dependencies if the currently-installed version is dropped from the repository. On the testing branch that happens a lot more often, but it will probably happen on stable more often than perhaps Igor desires. Keeping around package-versions that have been removed from the tree is problematic for a few reasons: 1. They could have security flaws and you'll never know. Gentoo does not issue security bulletins/etc for versions of packages no longer in our repository. 2. They could have compatibility issues and you'll never know. If foo v1,2,3 are in the tree and foo v1 doesn't work with bar, then bar will have a =foo-2 dependency. If only foo v2 and 3 are in the tree then the bar maintainer won't test it on v1, and won't exclude it from the dependencies most likely. This came up in the dynamic deps thread. Setting aside all those issues, suffice it to say that lots of bad things can go wrong when you start keeping around packages or package-versions which aren't in the tree. We don't do releases like other distros, so old data gets stale really fast. Rich
Re: [gentoo-dev] minimalistic emerge
On Fri, 2014-08-08 at 20:27 +0400, Igor wrote: I know no server that is automatically updated with -uDNav @world and works for more than 6 months. I would never auto-update.. That said, I installed this system in 2005. I can't keep a single system functional with auto-updates for just 6 months And that's why auto, unattended updates should never be used.. -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] minimalistic emerge
Kent, Friday, August 8, 2014, 7:51:22 PM, you wrote: There's no way to communicate to a user what you will and will not do with the software, so its impossible to know what flaws you will and won't encounter, so the dependencies thus declare a minimum for expected working behaviour for *all* a software's functionality, not just your user-specific subset. Maintainers have no feedback from their ebuilds, they all do their best but there are no tools to formalize their work. No compass. They have no access to user space where the packages are installed, unaware how users are using their ebuilds. It's the design failure that hunts Gentoo from the start - no global intellectual bug tracking system. Doing not mistakes - not possible, the automated tracking sub-systems should be there but... we are where we are. If the first portage had the stats in any shape Gentoo would be better now. A year ago I wanted to program it but I was in a very huge project that I'm still coding :-((( it's life or death project for me and I can't move out of it or I will sleep on a street. I appreciate all the work everyone is done on Gentoo in free time and I appreciate even more that you really found that time in this world and this life not saying but really doing. It's my best system and I only hope that someday I would be able to contribute to it as many of you did. If you wish to override that decision, you may, but your self-supporting from that point on. TL;DR = just because it works /for you/, doesn't mean it /isn't broken/ and doesn't mean the minimum declaration is unnecessary for all users. Agree. -- Best regards, Igormailto:lanthrus...@gmail.com
Re: [gentoo-dev] minimalistic emerge
Hello Homer, Friday, August 8, 2014, 8:40:20 PM, you wrote: I know no server that is automatically updated with -uDNav @world and works for more than 6 months. I would never auto-update.. That said, I installed this system in 2005. I can't keep a single system functional with auto-updates for just 6 months And that's why auto, unattended updates should never be used.. You're very brave saying it. Cheers! -- Best regards, Igormailto:lanthrus...@gmail.com
Re: [gentoo-dev] minimalistic emerge
On 9 August 2014 04:58, Igor lanthrus...@gmail.com wrote: Maintainers have no feedback from their ebuilds, they all do their best but there are no tools to formalize their work. No compass. They have no access to user space where the packages are installed, unaware how users are using their ebuilds. It's the design failure that hunts Gentoo from the start - no global intellectual bug tracking system. Doing not mistakes - not possible, the automated tracking sub-systems should be there but... we are where we are. Some of that is doable, ie: we could have installation metrics systems like CPAN has a testers network with a matrix showing where a given thing is failing : http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126 But its a lot of work investment to support. And beyond it installs and its tests pass, its piratically infeasible to track software failing beyond there. And some of the reasons we have dependency declarations are to avoid problems that will ONLY be seen at runtime and WONT be seen during installation or testing. ( Usually because the problem was found before there were tests for it ) For that, only manual feedback systems, such as our present bugzilla, are adequate. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] minimalistic emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/08/14 12:27 PM, Igor wrote: Hello Ian, Friday, August 8, 2014, 7:45:56 PM, you wrote: * -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igor - you need to read the emerge man page. emerge -uDNav @world is the recommended way to update your system, because then you will stay in sync with all appropriate updates in the portage tree. However, if you don't want to do this, just emerge -u @world -- that will only update packages in your world file, and will only force dependency updates when the new version is required (based on minimum versions in package dependencies). And if you only want to upgrade things piecemeal, then use --exclude [pkg] to skip updates, or emerge -1 [pkg] to only update an explicit list, or use /etc/portage/package.mask to avoid updating to newer versions. *It's unreliable, if you update system on daily basis - the system will get unstable and eventually will not even boot. It will be up-to-date but not functional. UDEV was the latest example :-( The updated system requires constant human assistance and the number of CRITICAL bugs is always constant (heart beat bug affected the latest systems but not old). I know no server that is automatically updated with -uDNav @world and works for more than 6 months. I would do it but I know that each time @world updated - I'm in a possible trouble. I need to check all config files, all daemons for changes, boot managers, mdadmin, web servers, mysql, udev, and the surprise will happen when you boot next time. May be in in 300 days, then you try to remember what was changed in 100 days, it's close to a hell. Of course. Gentoo in and of itself does not provide a distro that is out-of-the-box functioning at all times, like Debian or RHEL does/tries-to*. Updates do and always will require administrative maintenance, emerge (and paludis and pkgcore) is not a tool that's meant to be used in an automated fire-and-forget way, and the portage tree doesn't provide packages in such a fashion either. You will always have to use your head when packages upgrade, as to the effect that they will have on your system as a whole. If you do want to push (server) updates in an automated way, then you should have your own staging system that will build and host binpkg's, including the necessary (manually vetted) configuration updates, and have your servers pull those updates from the staging system. That way, you're still doing the due diligence that is required for updates - -and- you have a means of rolling these updates out in a mostly-automated fashion across multiple systems (whether they be homogeneous or not). [* this is only my perception of those projects, i have little knowledge of them, and what knowledge i do have is a decade out-of-date] Maintainers - don't have time to test packages against old versions, they just pull in the new versions in e-build with each is doing that and the resulting update is an enormous surplus. If a maintainer bumps the minimum version of an ebuild's dependencies, then it's done so for a reason and this really shouldn't be circumvented. However, standard portage updates (via --deep) will upgrade those dependencies to the latest stable in-tree version regardless of what the minimum version is in the ebuild. So the issue that you seem to be complaining about here doesn't have anything to do with maintainers and rather has to do with the way you're using emerge. * If you're asking for something even lighter than what 'emerge -u @world' will provide, on an automagic system-wide level, then i think you'll need to author some detailed specifications as to exactly what it is you want this new updating feature to do. Please note, though, that we as Gentoo developers can't guarantee that your system is going to remain stable if you don't update --deep, because we can't test every possible combination of every stable-keyworded dependency version against every package -- not even a tinderbox makes that particularly feasible, there's just too many permutations. I also am not sure at this time if 'emerge -u' would *You need to know what packages are installed and how they're installed world wide. That is the only way to stabilize Gentoo architecture. Firing updates not knowing what happened - is the lack of feedback that is hurting gentoo development. What? No. We are not going to only commit new ebuilds (or only stabilize ebuilds) for libraries on the basis of what versions other distros are currently using as stable, and building their entire package tree against. If you want that, then what's the point of using Gentoo in the first place? Gentoo's strength is in its ability to use arbitrary library versions (within certain restraints as specified by their consumers) for any dependency, and update them as new updates (with new features or bug fixes) are released upstream, and rebuild (when
Re: [gentoo-dev] minimalistic emerge
On Fri, 2014-08-08 at 21:26 +0400, Igor wrote: Hello Homer, Friday, August 8, 2014, 8:40:20 PM, you wrote: I know no server that is automatically updated with -uDNav @world and works for more than 6 months. I would never auto-update.. That said, I installed this system in 2005. I can't keep a single system functional with auto-updates for just 6 months And that's why auto, unattended updates should never be used.. You're very brave saying it. Cheers! No, I let the software do the work it's designed to do. Why would I fight it? -- Homer Parker hpar...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] minimalistic emerge
Kent Fredric wrote: dependencies are forward specifications from upstream telling us what their software needs to function properly. Unfortunately that's not the full story. :\ ebuilds often (for me) have artificial dependencies, when the actual version required is too old to be in the tree, but maybe not too old to be installed on an existing system. I think it's bad policy to lie about dependencies in ebuilds for the sole reason of only ever depending on versions which actually exist in the same snapshot. It's a too simplistic model of reality. //Peter
Re: [gentoo-dev] minimalistic emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/08/14 03:34 PM, Peter Stuge wrote: Kent Fredric wrote: dependencies are forward specifications from upstream telling us what their software needs to function properly. Unfortunately that's not the full story. :\ ebuilds often (for me) have artificial dependencies, when the actual version required is too old to be in the tree, but maybe not too old to be installed on an existing system. I think it's bad policy to lie about dependencies in ebuilds for the sole reason of only ever depending on versions which actually exist in the same snapshot. It's a too simplistic model of reality. For the most part I don't think that happens very often; usually if all stable versions of a dependency can satisfy a package's needs then there isn't any minimum version specification (or the minimum version specification hasn't actually been updated in an ebuild's *DEPEND, despite the older versions having been removed). The main exception to this is the work done related to gx86-multilib (as for obvious reasons the multilib ebuilds are needed to supply multilib dependencies), and the refactoring that mgorny did a few weeks back to fix the EAPI5 USE_EXPAND+IUSE_IMPLICIT undefined behaviour issue. That said, even if dependency atoms allow the older, no-longer-in-tree versions to satisfy a package's needs, as I said earlier I don't think any dev has the time and resources to test against anything older than latest-stable, and definitely not anything that's no longer in the tree. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPlKW0ACgkQ2ugaI38ACPDAewD/ebk6WQa4pA4VJQkpiXf2Ch/R uGz0HRy6/Y17eSxDL3wA/2gD8ciNsVWkIV6/kLGwwVXGItLL07A3OXITGLE1U8+N =EBWi -END PGP SIGNATURE-
Re: [gentoo-dev] minimalistic emerge
On 9 August 2014 07:34, Peter Stuge pe...@stuge.se wrote: ebuilds often (for me) have artificial dependencies, when the actual version required is too old to be in the tree, but maybe not too old to be installed on an existing system. The inverse is also true, sometimes you see people go: Well, upstream requires Foo 1.5 at least, but we have 2.0 as the oldest in tree, so we can just say dev-whatever/Foo and be done with it Which turns out to be horribly wrong if somebody still has Foo 1.4 installed, for whatever reason. And this is just one reason why being excessively lazy about what you upgrade could be secretly detrimental. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] minimalistic emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/08/14 03:56 PM, Kent Fredric wrote: On 9 August 2014 07:34, Peter Stuge pe...@stuge.se mailto:pe...@stuge.se wrote: ebuilds often (for me) have artificial dependencies, when the actual version required is too old to be in the tree, but maybe not too old to be installed on an existing system. The inverse is also true, sometimes you see people go: Well, upstream requires Foo 1.5 at least, but we have 2.0 as the oldest in tree, so we can just say dev-whatever/Foo and be done with it Which turns out to be horribly wrong if somebody still has Foo 1.4 installed, for whatever reason. And this is just one reason why being excessively lazy about what you upgrade could be secretly detrimental. Also very true. I don't think we have any sort of tree-wide policy on this either, do we? Although I believe common sense says it's a good idea (and i hope most devs do this) to put a minver on a dependency atom if there was any ebuild with an older version in the tree within the last year. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPlMC4ACgkQ2ugaI38ACPDUrgD+OiVN6HQKxNAOusj8PYI1O421 Dq2ihfhuQMz2HszG9DoBAJdTZJ9pRM6cFbkN+tcwFc/CAZUiWBe9MsSfoLkqho/C =T+NJ -END PGP SIGNATURE-
Re: [gentoo-dev] minimalistic emerge
Hello Kent, Friday, August 8, 2014, 9:29:54 PM, you wrote: But it's possible to fix many problems even now! What would you tell if something VERY simple is implemented like - reporting every emerge failed due to slot conflict back home with details for inspection? If maintainers had that kind of data then they could learn from the wild. I don't know what they would learn but I know it would be a very useful experience that might jump start evolution - useful updates to emerge and other tools. Almost every system designed by nature has feedback functions. It's the safe update - it will work even if not optimal from the start or even if it's not clear what it will help to learn. The quality of ebuilds would improve too. And from the useful life database new tools could evolve like - bug reporting automatization a whole new world of tool. http://db.gentoo.org/report/ System: System name Arch: Package emerged: Environment: Dependency graph: - ... - ... Fail message: * 3 reports per day are accepted from one single IP * no dups http://db.gentoo.org/stats/ - SlickGrid stats Arch Package How many times Failed Fail message Click on Package - Dependency Graph If GENTOO had everything emerging from any state (goal unattainable but desirable) that would be a great advantage for the users. That feel of a lean mean machine that saves time - it's tasty - new fans warranted. On 9 August 2014 04:58, Igor lanthrus...@gmail.com wrote: Maintainers have no feedback from their ebuilds, they all do their best but there are no tools to formalize their work. No compass. They have no access to user space where the packages are installed, unaware how users are using their ebuilds. It's the design failure that hunts Gentoo from the start - no global intellectual bug tracking system. Doing not mistakes - not possible, the automated tracking sub-systems should be there but... we are where we are. Some of that is doable, ie: we could have installation metrics systems like CPAN has a testers network with a matrix showing where a given thing is failing : http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126 But its a lot of work investment to support. And beyond it installs and its tests pass, its piratically infeasible to track software failing beyond there. And some of the reasons we have dependency declarations are to avoid problems that will ONLY be seen at runtime and WONT be seen during installation or testing. ( Usually because the problem was found before there were tests for it ) For that, only manual feedback systems, such as our present bugzilla, are adequate. -- Kent KENTNL - https://metacpan.org/author/KENTNL -- Best regards, Igormailto:lanthrus...@gmail.com
Re: [gentoo-dev] minimalistic emerge
Am Freitag 08 August 2014, 17:12:27 schrieb Igor: Hi, About 60% of all the packages are installed and work with nodep flag without any problems for years. Most of the maintainers just depend on new packages not knowing if it's necessary or not resulting in a really HUGE update that in the absolute majority of cases destabilize GENTOO making it not operational and WORSE than it was before. You then STABILIZE it again spending hours and then the story repeats itself. Experience show that out of 20 new dependencies pulled by emerge only 1 is critical and really needed to assemble the target. Is there any option in emerge to pull MINIMUM packages to get the result - install the application you need, leaving everything else AS IS untouched and stable? I would rather prefer and many would agree to use this kind of install instead of a full system update by default. Is there any USE flag that can switch system to this kind of update instead of conventional? If no such USE flag, what about stabilize gentoo with STABILIZED flag implementation in make.conf? Whoever needs everything new - can continue fighting with nature, the rest of us who has a limited life span - well, they might go for STABILIZED flag and live happily ever after. What do you think? /me is thinking: Your caps lock key is broken and about the content: man portage || use linux from scratch -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD
Re: [gentoo-dev] minimalistic emerge
On 9 August 2014 08:52, Igor lanthrus...@gmail.com wrote: Hello Kent, Friday, August 8, 2014, 9:29:54 PM, you wrote: But it's possible to fix many problems even now! What would you tell if something VERY simple is implemented like - reporting every emerge failed due to slot conflict back home with details for inspection? *-- Best regards, Igor* mailto:lanthrus...@gmail.com lanthrus...@gmail.com Yes. As I said, INSTALLATION metrics reporting is easy enough to do. I use those sorts of tools EXTENSIVELY with the CPAN platform, and I have valuable reports on what failed, what the interacting components were, and what systems the failures and passes occur on. So I greatly appreciate this utility. Automated bug reports however prove to be a waste of time, a lot of failures are in fact entirely spurious as a result of user error. So a metrics system that simply aggregates automated reports from end users that is observed as a side channel to bugs, proves more beneficial in reality. Usually all maintainers need here is a daily or even weekly digest mail summarising all the packages they're involved with, with their failure summaries, with links to the failures. ( For example, here is one of the report digests I received: http://i.imgur.com/WISqv15.png , and one of the reports it links to : http://www.cpantesters.org/cpan/report/ed7a4d9f-6bf3-1014-93f0-e557a945bbef ) And for such, you don't need to apply rate limiting, because multiple reports from a single individual prove to be entirely inconsequential, as you're not forced to deal with them like normal bugs, but are simply out of band feedback you can read when you have the time. And you can then make sense of the content of that report using your inside expertise and potentially file a relevant bug report based on extracted information, or use context of that bug report to request more context from its submitter. But the point remains that this techology is _ONLY_ effective for install time metrics, and is utterly useless for tracking any kinds of failures that emanate from the *USE* of software. If my firefox installation segv's, nothing is there watching for that to file a report. If firefox does something odd like renders characters incorrectly due to some bug in GPU drivers ( actual issue I had once ), nothing will be capable of detecting and reporting that. Those things are still bugs and are still bugs in packages and still bugs in packages that can be resolved by changing dependencies, but are however completely impossible to test for in advance of them happening as part of the installation toolchain. But I'm still very much on board with have the statistics system. I use it extensively, as I've said, and it is very much one of the best tools I have for solving problems. ( the very distribution of the problems can itself be used to isolate bugs. For instance, http://matrix.cpantesters.org/?dist=Color-Swatch-ASE-Reader%200.001000 Those red lights told me that I had a bug on platforms where perl floating point precision is reduced In fact, *automated* factor analysis pin pointed the probable cause faster than I ever could: http://analysis.cpantesters.org/solved?distv=Color-Swatch-ASE-Reader-0.001000 Just the main blockers are: - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] minimalistic emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/08/14 05:33 PM, Kent Fredric wrote: [ Snip! ] - Somebody has to implement this technology - That requires time and effort - People have to be convinced of its value - Integration must happen at some level somehow somewhere in the portage toolchain(s) - People must opt in to this technology in order for the reports to happen - And only then can this start to deliver meaningful results. *AND* (just to tie this back) it's unlikely that this is going to actually help the original issue posted, ie, reducing the amount of dependency updates being done unnecessarily on a system, or making blind/automated system updates (of the type mentioned in the thread) less susceptible to system breakage. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlPlQ58ACgkQ2ugaI38ACPAXawEAplg4MCOXTmY+MxJ4FpCYLnJ8 j/ETs84sy7MreBlWHaEA/jH8dEyJlQ8QAnJDftxmgiySwogdBweYQgaL6gPkxJTJ =Unnd -END PGP SIGNATURE-
Re: [gentoo-dev] minimalistic emerge
On 9 August 2014 09:39, Ian Stakenvicius a...@gentoo.org wrote: *AND* (just to tie this back) it's unlikely that this is going to actually help the original issue posted, ie, reducing the amount of dependency updates being done unnecessarily on a system, or making blind/automated system updates (of the type mentioned in the thread) less susceptible to system breakage. Yeah, if anything, that system is more likely to isolate previously unknown incompatibilities, establish *tighter* dependency ranges in order to satisfy them, and require *more* revision bumps and require you to update much more than you already do. So careful what you wish for :) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] minimalistic emerge
On Fri, Aug 8, 2014 at 4:16 PM, Ian Stakenvicius a...@gentoo.org wrote: I don't think we have any sort of tree-wide policy on this either, do we? Although I believe common sense says it's a good idea (and i hope most devs do this) to put a minver on a dependency atom if there was any ebuild with an older version in the tree within the last year. There is no reason not to specify a version constraint if you're aware of it. However, I wouldn't expect devs to go digging around in cvs for year-old package versions to test against them. If upstream happens to say it requires foo-1.5, by all means just take their word for it and list it, but more often than not they don't bother to test old versions either or note when the APIs they use were introduced. Rich
