Re: [gentoo-user] Re: Gentoo's future directtion ?
On Tue, 25 Nov 2014 20:29:28 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: And proposing a Java revolution because the existing team does not immediately jubilate at your extensive reform proposals is also not necessarily the best idea. For those that disagree, start overlay java2015 and prove him wrong. ^_^
Re: [gentoo-user] Re: Gentoo's future directtion ?
Ah, I apologize. I did not mean to quote anything (it happens automatically; I will start paying more attention to it). I was hoping he would remember his additions to the conversation at hand and could extrapolate on them.
Re: [gentoo-user] Re: Gentoo's future directtion ?
Hasufell, what are you referring to by attempts to make Gentoo more friendly to gaming? On Sat, Nov 29, 2014 at 1:38 PM, hasufell hasuf...@gentoo.org wrote: Alan Mackenzie: So that instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). [snipping everything that is not technical] How exactly is that a disadvantage? You are just complaining about the way a concept is presented without saying what actual limitations that implies (if any). If you like mercurial better, use that. Speaking about disadvantages however requires a bit more than I like that way better.
Re: [gentoo-user] Re: Gentoo's future directtion ?
On Tue, Dec 2, 2014 at 4:03 PM, Sid S r03...@gmail.com wrote: Hasufell, what are you referring to by attempts to make Gentoo more friendly to gaming? You quoted an email that didn't refer to attempts to make Gentoo more friendly to gaming. The reason that you should respond below quotes is so that readers can review the discussion in context. Your question is out of context, and top-quoted besides. You should also trim quotes that aren't relevant. Just a friendly request to try to bottom-quote in the future, and this is part of why. Obviously replying to the correct email is better, though bottom-quoting would help call your attention to the fact that this mistake was made. -- Rich
[gentoo-user] Re: Gentoo's future directtion ?
On Sat, Nov 29, 2014 at 07:09:07AM +, Martin Vaeth wrote: So for non-developers, downloading with git does not necessarily make sense. That being said, please do not consider this as an argument against a change to git: For developers it has only advantages, and AFAIK, it is not planned to cancel other download methods anyway. Of course. This is not going to be a requirement. Non-developers should stick with rsync. No one meant to replace rsync with Git. It is about replacing CVS with Git. -- Nicolas Sebrecht
Re: [gentoo-user] Re: Gentoo's future directtion ?
Hello, everybody. On Sat, Nov 29, 2014 at 07:09:07AM +, Martin Vaeth wrote: hasufell hasuf...@gentoo.org wrote: Martin Vaeth: hasufell hasuf...@gentoo.org wrote: With rsync I believe you can exclude categories: http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync That is uninformed. I think he is right. check the --depth option of git. You can even clone specific tags with --depth=1. Every tag will still contain all categories: AFAIK, with git, it is not possible to update everyting but e.g. *access* *kde* *i10n* *gnome* if you know that you will never install an ebuild from these categories. My max DL rate is ~700KiB/s and is the limiting factor. My concern is not the time but the total volume (there are still often limitations involved), and perhaps even more important, the disk usage, especially compared with methods like squashfs(+aufs). It simply is a fact that with git you have to download and store a lot of unnecessary information (if you are not a developer and do not use a heavy system): not only git metadata but also unneeded categories. So for non-developers, downloading with git does not necessarily make sense. That being said, please do not consider this as an argument against a change to git: For developers it has only advantages, and AFAIK, it is not planned to cancel other download methods anyway. Speaking as a developer in a project which has just converted to git, I can assure you that git has tremendous disadvantages, even compared with cvs. Principally, git does not have a high level model of version control concepts, so that using git is somewhat analogous to programming in assembler. Both give you tremendous control and the ability to do practically anything, including shooting yourself in the foot. So that instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). git is very difficult to learn, compared with, say Mercurial. To compare, if you do $ git help branch, you get a man page ~180 lines long dumped on you, and that's taking up the full width of my 240 character wide screen. If you do $ hg help branch, you get a 27 line concise summary, max. ~80 characters wide, which nonetheless is pretty much complete. git has become very popular (much as systemd has), possibly because programmers are frustrated at not being able to write in assembler any more. (At least, that's my theory). Like systemd, it has established a stranglehold on its domain. But severe disadvantages it most definitely has. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Gentoo's future directtion ?
On Sat, Nov 29, 2014 at 10:28 PM, Alan Mackenzie a...@muc.de wrote: Hello, everybody. Good day. instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). I actually see that as a more flexible approach. git is designed to be distributed and that's what everyone loves about it. For everything: http://stackoverflow.com/questions/802573/difference-between-git-and-cvs http://eclipsesource.com/blogs/2011/06/09/git-lessons-learned/ Cheers, konsolebox
Re: [gentoo-user] Re: Gentoo's future directtion ?
Hello, konsolebox. On Sat, Nov 29, 2014 at 11:18:49PM +0800, konsolebox wrote: On Sat, Nov 29, 2014 at 10:28 PM, Alan Mackenzie a...@muc.de wrote: Hello, everybody. Good day. instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). I actually see that as a more flexible approach. git is designed to be distributed and that's what everyone loves about it. We're in violent agreement, it seems. git is very flexible, just like programming in assembler is. git is certainly a distributed system, just like Mercurial, Bazaar, etc., but seems to be the only one of its kind that imposes this degree of flexibility on its users. Hence the multi-hundred line man pages for each of git's 155 sub-commands. Mercurial has a mere 50 sub-commands (plus, to be fair, a few one's going to need which are classified as extensions), and a single, very readable, man page ~8000 lines long. For everything: http://stackoverflow.com/questions/802573/difference-between-git-and-cvs http://eclipsesource.com/blogs/2011/06/09/git-lessons-learned/ Cheers, konsolebox -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Gentoo's future directtion ?
On 11/29/2014 09:28 AM, Alan Mackenzie wrote: Speaking as a developer in a project which has just converted to git, I can assure you that git has tremendous disadvantages, even compared with cvs. It depends; they do different things. Depending on what I'm working on, I use either subversion or git; neither is inherently better all the time. Principally, git does not have a high level model of version control concepts, so that using git is somewhat analogous to programming in assembler. Both give you tremendous control and the ability to do practically anything, including shooting yourself in the foot. So that instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). As far as I can tell, git has a very clear concept of branching. Fast branching was one of the biggest design points in git[1], and they did it by merely making branches pointers to avoid unnecessary copying. So yes, a branch is commits reachable from a certain HEAD, but conceptually this is the same as other branching models even though it may not be implemented the same way. git is very difficult to learn, compared with, say Mercurial. To compare, if you do $ git help branch, you get a man page ~180 lines long dumped on you, and that's taking up the full width of my 240 character wide screen. If you do $ hg help branch, you get a 27 line concise summary, max. ~80 characters wide, which nonetheless is pretty much complete. git has become very popular (much as systemd has), possibly because programmers are frustrated at not being able to write in assembler any more. (At least, that's my theory). Like systemd, it has established a stranglehold on its domain. But severe disadvantages it most definitely has. git is extremely popular, which could be a factor in its difficulty; I'm guessing it's had a lot more development hours (and more obscure features) put into it. git is popular because it solved (and still solves) a problem (distributed, parallel development) that at the time was not solved by any other open source DVCS except Mercurial. Both projects started around the same time, and I would imagine that having the Linux kernel team backing git was a compelling reason to choose git over Mercurial. Early on, iirc git was also faster since mercurial uses diffing, not snapshots, and is written in Python. I highly recommend Scott Chacon's Pro Git: http://git-scm.com/book/en/v2 Alec [1] http://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git
Re: [gentoo-user] Re: Gentoo's future directtion ?
Alan Mackenzie: So that instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). [snipping everything that is not technical] How exactly is that a disadvantage? You are just complaining about the way a concept is presented without saying what actual limitations that implies (if any). If you like mercurial better, use that. Speaking about disadvantages however requires a bit more than I like that way better.
Re: [gentoo-user] Re: Gentoo's future directtion ?
Martin Vaeth: hasufell hasuf...@gentoo.org wrote: With rsync I believe you can exclude categories: http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync That is uninformed. I think he is right. check the --depth option of git. You can even clone specific tags with --depth=1. Every tag will still contain all categories: AFAIK, with git, it is not possible to update everyting but e.g. *access* *kde* *i10n* *gnome* if you know that you will never install an ebuild from these categories. My max DL rate is ~700KiB/s and is the limiting factor. # time git clone --depth=1 --branch=v3.1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git real2m56.615s user0m5.802s sys 0m0.578s So the initial comment A good example of why I don't think they will be using git for portage: ``git clone https://git.kernel.org' doesn't make much sense, because it isn't the recommended way to clone the kernel tree.
Re: [gentoo-user] Re: Gentoo's future directtion ?
James: hasufell hasufell at gentoo.org writes: I still don't see a good argument why we made our system so inflexible, that obviously needed change needs such high amount of work, PR and proof. I think that most folks appreciate your efforts and insightful ideas on how to open up development, particularly in non-critical (non-core) areas. The quesiton is how do we get from where we are to where we want to be. I find most of what I'm interested in already in Arch Linux. I wonder why it is so much easier for Arch users to create pkgbuilds (like gentoo's ebuilds) and find a dev to adopt the package? Surely someone has some insight on this differences, or do I miss something that creats the difference? [1] I also find the Arch documentation to be of the finest quality of any and all linux distros, close to gentoo. ymmv. Arch has done it wrong, IMO. Sure, their PKGBUILDs are easier to write, but their quality is also worse. I know how to write them and have written and looked at a lot of them. People went the easy way and didn't really care much about review workflow, so they ended up with AUR where everyone can upload random stuff, including dangerous and wrong code. Trying to improve a tiny fraction about gentoo workflow (including your attempts) already took more than 4(?) years with never ending excuses. The necessity was more than obvious. Now I could talk about similarly obvious things. Sure, not all issues are obvious and those shouldn't be easy to push through. Everyone understands small changes and all changes take time for the majority of members to digest, imho. Not everyone has your keen insight into the problem/opportunity. So your patience in explanation, encouragement and solicitation, is very important, if your idea is to be implemented and tested. Naturally, Rich and other deeply involved devs, with addtional responsibilities exude caution, to keep the gentoo stable. They will not be the source of team building for your idea, imho. Gentoo isn't even particularly stable anymore. It's a mess to maintain with a confused PM, toolchain hackery and random conflicting ideas in one repository (e.g. multilib clashing with crossdev). The distro can only be as stable as the PM and the PM depends on the input. The input depends on quality ebuilds. Quality ebuilds depend on a proper spec, but there is no proper spec... PMS team itself says it started as a collection of ancient portage behavior and then grew with time, so there was no real design behind it. Quality ebuilds also depend on review-workflow. Review-workflow needs proper tools. We don't even have the last one. Long way to go. Good luck. You can draw your conclusions about this. I drew mine: small changes will not get us out of here. I think the jury is still out. So, why can't we test a transient plan where we take something very broken areas at Gentoo (games or java or sys-cluster) and test out your hypothesis for package development expansion? Already doing so https://github.com/hasufell/games-overlay and that's where I will update ebuilds, not in the tree. And I don't care to get any of that into the tree. In fact, I've been looking over quite a few ebuilds and pkgbuilds at (Arch linux). [2] I see quite a lot of commonality. So, why can we not modify this aforementioned inflexible system on gentoo to allow for Arch Linux pkgbuilds to be routinely compiled and installed on gentoo? Maybe limit the test to /usr/local/portage or /usr/local/portage/test/ so folks can participate or purge the experiment? Maybe find some Arch linux devs keen on the idea of developing/evolving package management so that the two distros can readiy (or more easily) convert packages between Arch and Gentoo? Is it possible? Could your plan be modified to include a variety of Arch developers? Surely you have a collection of devs ready to implement your keen ideas? I, for one realize something fundamental has to change with Gentoo, after pushing a few months on java and cluster codes Also, there is a vast array of software, of various quality, among the overlay repositories to use as test-packages? The biggest thing I seen wrong with Arch is they have forced systemd onto their users, and all of the arch users I know, are not very happy about that. So if you approach this correctly, I'm sure quite a few Arch linux folks would also test your offerings. Have fun, if you can. Always we should have fun. That is why we should deeply discuss these issues to find common ground. Maybe fixing this inflexible system should involve a survey of those distros closest to gentoo, for ideas, particulary several (structured) methods to install packages, provide choices for the init system, and strongly advocate package development within the ranks of the user base. Clear and concise documentation, concurrent with this effort is probably your single greatest alley, should your idea
[gentoo-user] Re: Gentoo's future directtion ?
hasufell hasufell at gentoo.org writes: Already doing so https://github.com/hasufell/games-overlay and that's where I will update ebuilds, not in the tree. And I don't care to get any of that into the tree. OK. People are scared of other gentoo-like distros/PMs. Exherbo is evil, paludis is evil, sabayoon is evil, ... I agree, there is much resistence and calcification deep in the ranks of gentoo. I've already tried contributing to exherbo. They are technically ahead of us in some non-trivial areas, but I don't think they have solved the contribution problem. Sure, they are more distributed and have gerrit etc, but their review workflow goes more the way make a high-quality user-overlay and then we will review it once and add it to our page. As a young distro, maybe that's all the man_hours they have for outside packages right now? They don't care too much about themed and clearly scoped overlays and about the difference of 'modular' and 'fragmented'. 200 guys pushing into 200 repositories without _regular_ reviews (not just a gentoo dev or high quality overlay badge) is not much different to what gentoo does. Is this (above) aimed at Exherbo or Arch? Arch is neither interesting from the technical nor from the workflow standpoint, IMO. It has been around for a while. OK so keep in mind if you are successful at what you set up (your overlay ++) with gentoo, I'd be interested to know the details and maybe I'll move my codes to a similar structure; mostly java and science/math codes Drop me private email, or keep me informed whatever your chosen information dispersement is (a blog? etc) as your code development mechanisms evolve. sincerely, James
[gentoo-user] Re: Gentoo's future directtion ?
hasufell hasuf...@gentoo.org wrote: Martin Vaeth: hasufell hasuf...@gentoo.org wrote: With rsync I believe you can exclude categories: http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync That is uninformed. I think he is right. check the --depth option of git. You can even clone specific tags with --depth=1. Every tag will still contain all categories: AFAIK, with git, it is not possible to update everyting but e.g. *access* *kde* *i10n* *gnome* if you know that you will never install an ebuild from these categories. My max DL rate is ~700KiB/s and is the limiting factor. My concern is not the time but the total volume (there are still often limitations involved), and perhaps even more important, the disk usage, especially compared with methods like squashfs(+aufs). It simply is a fact that with git you have to download and store a lot of unnecessary information (if you are not a developer and do not use a heavy system): not only git metadata but also unneeded categories. So for non-developers, downloading with git does not necessarily make sense. That being said, please do not consider this as an argument against a change to git: For developers it has only advantages, and AFAIK, it is not planned to cancel other download methods anyway.
[gentoo-user] Re: Gentoo's future directtion ?
hasufell hasuf...@gentoo.org wrote: With rsync I believe you can exclude categories: http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync That is uninformed. I think he is right. check the --depth option of git. You can even clone specific tags with --depth=1. Every tag will still contain all categories: AFAIK, with git, it is not possible to update everyting but e.g. *access* *kde* *i10n* *gnome* if you know that you will never install an ebuild from these categories.
[gentoo-user] Re: Gentoo's future directtion ?
hasufell hasufell at gentoo.org writes: I still don't see a good argument why we made our system so inflexible, that obviously needed change needs such high amount of work, PR and proof. I think that most folks appreciate your efforts and insightful ideas on how to open up development, particularly in non-critical (non-core) areas. The quesiton is how do we get from where we are to where we want to be. I find most of what I'm interested in already in Arch Linux. I wonder why it is so much easier for Arch users to create pkgbuilds (like gentoo's ebuilds) and find a dev to adopt the package? Surely someone has some insight on this differences, or do I miss something that creats the difference? [1] I also find the Arch documentation to be of the finest quality of any and all linux distros, close to gentoo. ymmv. Trying to improve a tiny fraction about gentoo workflow (including your attempts) already took more than 4(?) years with never ending excuses. The necessity was more than obvious. Now I could talk about similarly obvious things. Sure, not all issues are obvious and those shouldn't be easy to push through. Everyone understands small changes and all changes take time for the majority of members to digest, imho. Not everyone has your keen insight into the problem/opportunity. So your patience in explanation, encouragement and solicitation, is very important, if your idea is to be implemented and tested. Naturally, Rich and other deeply involved devs, with addtional responsibilities exude caution, to keep the gentoo stable. They will not be the source of team building for your idea, imho. You can draw your conclusions about this. I drew mine: small changes will not get us out of here. I think the jury is still out. So, why can't we test a transient plan where we take something very broken areas at Gentoo (games or java or sys-cluster) and test out your hypothesis for package development expansion? In fact, I've been looking over quite a few ebuilds and pkgbuilds at (Arch linux). [2] I see quite a lot of commonality. So, why can we not modify this aforementioned inflexible system on gentoo to allow for Arch Linux pkgbuilds to be routinely compiled and installed on gentoo? Maybe limit the test to /usr/local/portage or /usr/local/portage/test/ so folks can participate or purge the experiment? Maybe find some Arch linux devs keen on the idea of developing/evolving package management so that the two distros can readiy (or more easily) convert packages between Arch and Gentoo? Is it possible? Could your plan be modified to include a variety of Arch developers? Surely you have a collection of devs ready to implement your keen ideas? I, for one realize something fundamental has to change with Gentoo, after pushing a few months on java and cluster codes Also, there is a vast array of software, of various quality, among the overlay repositories to use as test-packages? The biggest thing I seen wrong with Arch is they have forced systemd onto their users, and all of the arch users I know, are not very happy about that. So if you approach this correctly, I'm sure quite a few Arch linux folks would also test your offerings. Have fun, if you can. Always we should have fun. That is why we should deeply discuss these issues to find common ground. Maybe fixing this inflexible system should involve a survey of those distros closest to gentoo, for ideas, particulary several (structured) methods to install packages, provide choices for the init system, and strongly advocate package development within the ranks of the user base. Clear and concise documentation, concurrent with this effort is probably your single greatest alley, should your idea and leadership prove successful. hth, James [1] http://www.volkerschatz.com/unix/ebuilds/ebuilds.html [2] https://aur.archlinux.org/packages/sl/slurm-llnl/PKGBUILD
Re: [gentoo-user] Re: Gentoo's future directtion ?
Am Montag 24 November 2014, 18:13:56 schrieb James: If you want java to prosper at Gentoo, it's gonna take an inner-circle gentoo-dev to at least cheerlead for java within gentoo, imho. I'm not really sure what this inner-circle stuff is supposed to mean. You need a gentoo-dev who is interested and willing to talk to and to listen to the existing java team members, and willing to invest quite some time and effort. I have absolutely no clue about the state of java in Gentoo, but for the sake of the argument let's assume that the team is understaffed and the ebuild architecture is in need of a general overhaul. Then what one would have to do is understand how things are done now and why (listening helps sometimes more than talking talking talking). Java has some pretty complex eclasses, so it'll take some time until you understand them. First start with small improvements and then with bigger steps. At some point you get along with the existing team and plan the big reforms with them. This may need dedication and patience, and is not always best served by the CADT phenomenon. It definitely does not get better by forking the code into N random overlays. And proposing a Java revolution because the existing team does not immediately jubilate at your extensive reform proposals is also not necessarily the best idea. ok now I just have to go to Starbucks. -- Andreas K. Huettel Gentoo Linux developer kde, council
[gentoo-user] Re: Gentoo's future directtion ?
Rich Freeman rich0 at gentoo.org writes: The reason I jumped into this thread is that someone had problems with the java project. I'm not sure, but maybe something is wrong with my eyes? Your eyes are fine. Gmane's web interface was hosed. I tried to use nntp (earlybird) but that interface does not consistently respond to the thread, so hacking at the settings and posting(tests) seems to upset some. I appreciate your ideas, I mostly like the ideas of distributed development for non core modules. I also believe and Rich as articulated, that we mostly have thing now. Where I diagree with Rich is this. Sure, If somebody has been a gentoo dev for years, has push access then they can get coding completed. If you are new to the depths of what gentoo devs do, then it is opaque as to which docs to read, dealing with the technical details that are currently used and which are either not documented or poorly documented, etc etc. It's not that any of the devs have a desire to keep folks from becoming deeply capable devs such as themselves, it that these elites spend very little time, paving a path for others fledgling devs; so the the cost barrier to gaining inside (current) knowledge is very him, imho. Most will just drift to anothe distro where that sort of help is more redily available. Thank god for SVEN. But, he cannot clean up the myriad of docs that need tlc. What you do not seem to comprehend Rich, is what most non super_devs want is some help, imho. Just look back at your harsh postings on java. It's rather crushing for folks that want to use Java. Quite simply, I'm developing the skills to use java on gentoo. Those keen developers within the java team, are spread very thin; just look at what they are recruiting for: http://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs So I understand that you are not interested in Java. So, how do we find or develop a gentoo-inner-circle-java-interested dev? With out that java does not have a chance to gain traction within gentoo, imho. OK, so dont beat me up for being lazy (stupid as volker points out routinely) just *help me* via private email who at Gentoo is the java wizard? I'll do tons of grunt work to make then happy.? OK? Oh shit: problem one. Go clean up BGO's java bugs. I cant because it has become a circular cluster_F!. Too many old blocking bugs; nobody (who gives a shit) with the authority to purge java bugs. And my point was that the only problem I see with Java is that nobody is actually working on it. If nobody works on distributed java repositories, it will be just as bad. Rich, there are billions of Java codes, available in source form that can easily have ebuilds created. But we have poor support for maven, etc. So they go nowhere. (I believe a gentoo-dev for maven is the blocker here. I know that Maven is not easy. I am not (yet) close to being qualified to work on deep maven issues withing gentoo. My specific request was WHO is trying to do something to improve Java and finding a policy that is preventing them from doing so, and WHAT policy is causing the problem? see details above? It is easy to talk about vague problems. It is harder to actually pinpoint specific issues that can actually be fixed. Please don't take this as a personal attack - I generally have a lot of respect for you. I just don't think that this is a helpful way of approaching these problems. Ah, I think Hasufell has very good intentions and some keen ideas. My fear is java is getting not love from the gentoo innner circle. So we reduce the innner circle dev count, move java to the perimeter (where nobody cares that is remotely connected to the inner-circle) and java get's better? I've seen this sort of thing thousands of times in my life. Java will just be purged from Gentoo, reticent on your previous postings about your feelings towards Java. Another council member in 2013 was all encouraging about gentoo-clustering. But now that clustering is mostly java centric (imho), few at Gentoo care about cluster on gentoo. Convenient. Sad. Not really encourage to the fledgling community that are willing to work on java, but need leadership. I put (2) ebuilds into BGO. apache-mesos and apache-spark. bugs 510912 and 523412. There they languish. Following the outside overlay semantic guidance, newer versions are here, thanks to Alec: https://github.com/trozamon/overlay/tree/master/sys-cluster So as you point out, go and work on what you want. Really? You think they'll get move to the gentoo tree any time soon? I'm mostly looking for help, encouragement and guidance. I am not looking for harsh reponses that are discouraging. I am not trying to harash you, I appreciate what you do for Gentoo, very much. I get you are not interested in anything remotely connected to java. I would appreciated your keen insight into finding us a java leader that is not burnt to a crisp by the gentoo-stress-burnout syndrome that seems to
[gentoo-user] Re: Gentoo's future directtion ?
On Sat, Nov 22, 2014 at 06:20:01PM -0500, Rich Freeman wrote: Don't get me wrong, I'm all for more overlay support. I'm all for reform when there is something to reform. However, in all your complaints about developers causing conflicts you're actually becoming part of the problem. I'd say the problem is not about the devs themselves causing conflicts but the environment and frame devs are working in the current workflow. Everybody look baffled with the current way of doing things in Gentoo. I agree with hasukel that the distributed Gentoo as proposed today is a wrong answer. Not that the issues raised are not valid. They do. Also, I agree with hasukel that the main problem is about having a correct distributed model. Posting on bugzilla for ebuilds updates or new ebuilds is seriously damaging when almost every where else it is just about sending your git patches. Becoming an official Gentoo dev is not a solution either due to the recruiting process. As you say, official devs can work on whatever they like and their contributions will likely hit the users at some point while at the same time occasional devs are asked to work with old tools like bugzilla. So yes, the whole review process is broken and the contribution process is broken too. About that, there's no other way than break the whole recruiting process and change of tools. Have your core team handle git repositories and let others request pull or send patches like almost all the other open source softwares in the world. Let's exploit the anarchy and openness instead of partitionning things into devs/non-devs or main-tree/overlays. Back to the original request. Here is how starts the distributed Gentoo model: Imagine you would say I like gentoo, but I don't like the way the toolchain is handled, so I want to do it differently. Currently, your only way is to fork the whole distro or do dangerous stuff with overlays. Imagine gentoo would actually be a small repository of core packages with lots of optional user contributed extenions of all kinds. You'd only need to fork the core and add those extensions you like. Similarly... you don't like the way ruby is handled? Well, apart from dev-lang/ruby maybe, there'd be no ruby gems in the tree anyway. So there can be different approaches of packaging ruby gems and you choose which to use or if you want to do it completely different. And there would be no complicated configuration required to prevent in-tree ruby packages getting pulled in, because there are none. Isn't this all stuff about handling some kind of pointers? Don't like the toolchain? Point to another one. Don't like the way ruby is handled? Point to another one. So, is it about overlays? No. I'd say overlays are some kind of poor pointers for many reasons. Hence, why not adding the pointers we are all missing and rethinking the other pointers? -- Nicolas Sebrecht
Re: [gentoo-user] Re: Gentoo's future directtion ?
Am 23.11.2014 um 16:18 schrieb Nicolas Sebrecht: On Sat, Nov 22, 2014 at 06:20:01PM -0500, Rich Freeman wrote: Don't get me wrong, I'm all for more overlay support. I'm all for reform when there is something to reform. However, in all your complaints about developers causing conflicts you're actually becoming part of the problem. I'd say the problem is not about the devs themselves causing conflicts but the environment and frame devs are working in the current workflow. Everybody look baffled with the current way of doing things in Gentoo. I agree with hasukel that the distributed Gentoo as proposed today is a wrong answer. Not that the issues raised are not valid. They do. Also, I agree with hasukel that the main problem is about having a correct distributed model. Posting on bugzilla for ebuilds updates or new ebuilds is seriously damaging when almost every where else it is just about sending your git patches. Becoming an official Gentoo dev is not a solution either due to the recruiting process. As you say, official devs can work on whatever they like and their contributions will likely hit the users at some point while at the same time occasional devs are asked to work with old tools like bugzilla. So yes, the whole review process is broken and the contribution process is broken too. About that, there's no other way than break the whole recruiting process and change of tools. Have your core team handle git repositories and let others request pull or send patches like almost all the other open source softwares in the world. Let's exploit the anarchy and openness instead of partitionning things into devs/non-devs or main-tree/overlays. Back to the original request. Here is how starts the distributed Gentoo model: Imagine you would say I like gentoo, but I don't like the way the toolchain is handled, so I want to do it differently. Currently, your only way is to fork the whole distro or do dangerous stuff with overlays. Imagine gentoo would actually be a small repository of core packages with lots of optional user contributed extenions of all kinds. You'd only need to fork the core and add those extensions you like. Similarly... you don't like the way ruby is handled? Well, apart from dev-lang/ruby maybe, there'd be no ruby gems in the tree anyway. So there can be different approaches of packaging ruby gems and you choose which to use or if you want to do it completely different. And there would be no complicated configuration required to prevent in-tree ruby packages getting pulled in, because there are none. Isn't this all stuff about handling some kind of pointers? Don't like the toolchain? Point to another one. Don't like the way ruby is handled? Point to another one. So, is it about overlays? No. I'd say overlays are some kind of poor pointers for many reasons. Hence, why not adding the pointers we are all missing and rethinking the other pointers? am I the only one who thinks that this way leads to madness? Version conflicts are bad enough. No multiply that with a bunch of overlays, all having their own libXY with just some tiny, tiny differences, and another bunch of overlays who want libXY from certain others if that does not give you nightmares, I don't know what.
[gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 04:31:45PM +0100, Volker Armin Hemmann wrote: am I the only one who thinks that this way leads to madness? Version conflicts are bad enough. First, version conflicts have their roots in the support for versions of libraries in softwares. This is the best place to fix that when possible. When it comes to ebuilds maintainers, version conflicts are about all about DECLARATIONS. If software A need Y-v1..12, we should have a way for the maintainers to declare that A relies on Y-v1..12 and let the dependency softwares to the hard job and admin/users handle them the way they want. Today, this is badly managed with implicit expectations everywhere. Also, there are ways to overcome version conflicts. Slots are one of them. No multiply that with a bunch of overlays, all having their own libXY with just some tiny, tiny differences, and another bunch of overlays who want libXY from certain others That's a reason why I said that overlays are a poor kind of pointers. For overlay maintainers today, if the main portage tree does not offer what they expect, the only option they have is to rewrite their own static dependency tree with their own ebuilds. That sucks. Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. -- Nicolas Sebrecht
Re: [gentoo-user] Re: Gentoo's future directtion ?
Am 23.11.2014 um 18:33 schrieb Nicolas Sebrecht: On Sun, Nov 23, 2014 at 04:31:45PM +0100, Volker Armin Hemmann wrote: am I the only one who thinks that this way leads to madness? Version conflicts are bad enough. First, version conflicts have their roots in the support for versions of libraries in softwares. This is the best place to fix that when possible. When it comes to ebuilds maintainers, version conflicts are about all about DECLARATIONS. If software A need Y-v1..12, we should have a way for the maintainers to declare that A relies on Y-v1..12 and let the dependency softwares to the hard job and admin/users handle them the way they want. Today, this is badly managed with implicit expectations everywhere. Also, there are ways to overcome version conflicts. Slots are one of them. No multiply that with a bunch of overlays, all having their own libXY with just some tiny, tiny differences, and another bunch of overlays who want libXY from certain others That's a reason why I said that overlays are a poor kind of pointers. For overlay maintainers today, if the main portage tree does not offer what they expect, the only option they have is to rewrite their own static dependency tree with their own ebuilds. That sucks. Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. and you want portage to finish on this site of eternity when looking for dependency resolution?
[gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 07:25:26PM +0100, Volker Armin Hemmann wrote: and you want portage to finish on this site of eternity when looking for dependency resolution? I don't think having exposed requirements would explode the time needed to calculate the dependency tree because this does not add paths to the tree. It only validates or invalidates paths. And if time for dependency resolution would become a real problem, there are ways to solve that. One could be making pre-calcultated caches of parts of tree/paths. -- Nicolas Sebrecht
Re: [gentoo-user] Re: Gentoo's future directtion ?
Am 23.11.2014 um 19:54 schrieb Nicolas Sebrecht: On Sun, Nov 23, 2014 at 07:25:26PM +0100, Volker Armin Hemmann wrote: and you want portage to finish on this site of eternity when looking for dependency resolution? I don't think having exposed requirements would explode the time needed to calculate the dependency tree because this does not add paths to the tree. It only validates or invalidates paths. And if time for dependency resolution would become a real problem, there are ways to solve that. One could be making pre-calcultated caches of parts of tree/paths. which works so well with different useflags. portage is already almost unbearable slow. The 'distributed model' would add so much complexity, we can forget USE. For what gains?
Re: [gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht nicolas.s-...@laposte.net wrote: Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. This sounds nice in principle, but making it work is not trivial. Suppose my package works with gcc-1.2.3.4 with a list of 14 specific patches and no others, and glibc-1.2.3.4 with another list of 14 patches and no others. Now suppose 300 other packages have similar requirements. First, expressing that without losing your mind is going to be VERY painful. You basically end up having to use content-hashed packages or something like that. You also end up with 300 copies of glibc in RAM and so on. Second, good luck dealing with security patches and bugfixes. You now have 300 copies of glibc to update, and since your list of dependencies stated that you have 14 patches and no others you now need to update the 300 other packages to use the newer version of glibc. The current Gentoo way is far more limiting, but by having a single version of glibc with a single policy around versioning/etc packages don't have to micromanage what they depend on. If NixOS/etc have found a better solution I'm all ears, but it is hard to tell based on the info on their website. It seems hard to me to allow so much diversity in dependencies without basically having every package on your system running in its own container (thus consuming a lot more RAM), and while managing security updates in a sane way. -- Rich
[gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote: On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht nicolas.s-...@laposte.net wrote: Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. This sounds nice in principle, but making it work is not trivial. Suppose my package works with gcc-1.2.3.4 with a list of 14 specific patches and no others, and glibc-1.2.3.4 with another list of 14 patches and no others. Now suppose 300 other packages have similar requirements. To make it simple, this is almost irrelevant IMHO. It won't happen because we are talking about patches required as dependency excluding other patches required as dependency on the same sources. IOW, we must notice that we would need multiple *installed* versions ONLY IF a dependency requirement is not met AND that this requirement is *excluding* one of the current gcc requirements. So, when they are non-compatible themselves in some way at the source level. On top of that, this would have to be an issue that has to be handled by the software devs. Second, good luck dealing with security patches and bugfixes. You now have 300 copies of glibc to update, and since your list of dependencies stated that you have 14 patches and no others you now need to update the 300 other packages to use the newer version of glibc. The current Gentoo way is far more limiting, but by having a single version of glibc with a single policy around versioning/etc packages don't have to micromanage what they depend on. Well, I wouldn't worry about that because having 300 versions of gcc (or any other package) is not the purpose. But it is a very good thing to restart the thread from patches handling like you did since it is the basis of software updates. When it comes to building a real and flexible meta-distribution (after all, this thread is all this issue), it is nice to have the packages management tools working for you. Also, it is good to keep in mind that everybody in the chain from the software developers to the users including fork developers, package-distro maintainers, sysadmin and the final users might want to tune their systems at some point. They are all some kind of forkers with the current Gentoo. Starting from there, the tools should not only allow them to do what they want but also help them in that task WHITOUT forking. If it's not the case, you end up with overlays or similar technics whose come which much more damaging problems in practice. All distributions manage vanilla sources + patches (including security patches and bugfixes). We start from vanilla with compilation options. Each one is declared so they are enabled/disabled easily (use flags...). Would it be that hard to declare if the patch add/remove/change a dependency? I don't think so. Now comes the series of patches management. Would it be hard to have the tools allowing to tune the series of patches that are going to be applied? I don't think so, either. Would it be hard to have the tools allow each role to tune/configure the system for both useflags and series of patches? Neither, we know how to do that kind of things since decades. So, when there are security fixes or bugfixes we don't need anything much crazy to handle them: the management of series of patches is already supported of the tools. Today, ebuilds don't even let a chance for an admin to apply a series of patches to the vanilla/distro-maintainer sources without having to rewrite/fork the ebuild. Whatever it is critical for them. The lone option is to fork+overlay. This is a serious issue FMPOV. If NixOS/etc have found a better solution I'm all ears, but it is hard to tell based on the info on their website. It seems hard to me to allow so much diversity in dependencies without basically having every package on your system running in its own container (thus consuming a lot more RAM), and while managing security updates in a sane way. I don't know about NixOS/etc. I'll look at that. About containers, they are usefull for solving other problems like testing, deployement or required isolation, IMO. -- Nicolas Sebrecht
[gentoo-user] Re: Gentoo's future directtion ?
On Sun, Nov 23, 2014 at 08:15:26PM +0100, Volker Armin Hemmann wrote: which works so well with different useflags. Yes, things need improvements. -- Nicolas Sebrecht
Re: [gentoo-user] Re: Gentoo's future directtion ?
Am 23.11.2014 um 21:54 schrieb Nicolas Sebrecht: Today, ebuilds don't even let a chance for an admin to apply a series of patches to the vanilla/distro-maintainer sources without having to rewrite/fork the ebuild. Whatever it is critical for them. The lone option is to fork+overlay. This is a serious issue FMPOV. that is not true. the rest: too long for me to read on a sunday night.
Re: [gentoo-user] Re: Gentoo's future directtion ?
On 23/11/2014 22:54, Nicolas Sebrecht wrote: On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote: On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht nicolas.s-...@laposte.net wrote: Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. This sounds nice in principle, but making it work is not trivial. Suppose my package works with gcc-1.2.3.4 with a list of 14 specific patches and no others, and glibc-1.2.3.4 with another list of 14 patches and no others. Now suppose 300 other packages have similar requirements. To make it simple, this is almost irrelevant IMHO. I'll tell you what I'm seeing. I'm seeing a theoretical description of magic software that mathematics predicts can exist. I don't see running software. How about you write running software that does what you describe, then we can talk more, m'kay? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Gentoo's future directtion ?
Am 23.11.2014 um 22:14 schrieb Alan McKinnon: On 23/11/2014 22:54, Nicolas Sebrecht wrote: On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote: On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht nicolas.s-...@laposte.net wrote: Portage should support a way to expose ALL the conditions for a software to work and update installed libraries to match the requirements. This sounds nice in principle, but making it work is not trivial. Suppose my package works with gcc-1.2.3.4 with a list of 14 specific patches and no others, and glibc-1.2.3.4 with another list of 14 patches and no others. Now suppose 300 other packages have similar requirements. To make it simple, this is almost irrelevant IMHO. I'll tell you what I'm seeing. I'm seeing a theoretical description of magic software that mathematics predicts can exist. I don't see running software. How about you write running software that does what you describe, then we can talk more, m'kay? oh, the magical cantation known as 'write the code or shut up' ...
