Re: Limitations of Ports System
On Fri, 11 Jan 2008 20:32:55 -0800 (PST) Tim Clewlow [EMAIL PROTECTED] wrote: Also I have the following options on in /etc/make.conf. CFLAGS= -O -pipe# Optimize general builds COPTFLAGS= -O -pipe # Optimize kernel builds I would suggest you remove these since they are overriding better defaults in the system makefiles. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On 13/12/2007, Brian [EMAIL PROTECTED] wrote: I just wonder if you asked the general population, whether they'd rather have ports or packages, I bet most would vote for packages, aside from those that actually like watching the compilation output fly by. I do like to watch it but in addition I always like to compile my own binaries etc. rather than using something thats precompiled and limited to how the compiler compiled it. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
--- Chris [EMAIL PROTECTED] wrote: On 13/12/2007, Brian [EMAIL PROTECTED] wrote: I just wonder if you asked the general population, whether they'd rather have ports or packages, I bet most would vote for packages, aside from those that actually like watching the compilation output fly by. I do like to watch it but in addition I always like to compile my own binaries etc. rather than using something thats precompiled and limited to how the compiler compiled it. Chris I change options in the mplayer Makefile to include twolame and mencoder in the build because that way you get more codecs available for mencoder. Also, MySQL has WITH_OPENSSL=yes in the make, and in PHP make config, I select Build Apache module. Also I have the following options on in /etc/make.conf. CFLAGS= -O -pipe# Optimize general builds COPTFLAGS= -O -pipe # Optimize kernel builds NO_PROFILE= # Only need to uncomment this line, no options Finally, as a rule I install the latest patched up version of stable 6.x from this optimised build (build once on a master cvs/build server). Dont know how many other people do this, but I definately prefer ports over packages. Cheers, Tim. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Linimon wrote: Side note the more we discuss this the more obvious it becomes to me it has to be in some OO lang and since C++ is the only one in the base system it kind of forces C++ to be the implementation lang. You may want to take a look at some of the work OpenBSD has done recently; I believe they are working towards treating ports as first-class objects. Actually that is one of the key reasons for C++ vs. C is if we treat a port as a first class object it becomes pretty trivial to manipulate it in a DAG without having to worry about any nasty details until we build it. - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZOoMzIOMjAek4JIRAlhEAJ0SSDnFWD184hMGHFjEtrT6DqPv3gCdEzD/ ak3puLnBhSL6ZjZtZOBGYRU= =hBcQ -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Saturday 15 December 2007 13:28:40 Aryeh M. Friedman wrote: you do not maintain any ports Incorrect I have one that is currently officially pending in the backlog created by the freeze (the PR is sitting their waiting). Also as soon that port is done and any errors I may of made as it being my first port I have 2 more to be added and on a fairly regular basis see adding to that list. Good of you to post the information however undeserving the person to whom you replied was of it. I see no need to defend against people who lack the maturity to behave collegially. David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Saturday 15 December 2007 01:25:11 pm David Southwell wrote: My intention is not to offend but to draw attention to the need to remain on topic and not to argue ad personam. On Sunday 16 December 2007 03:33:55 am David Southwell wrote: Good of you to post the information however undeserving the person to whom you replied was of it. I see no need to defend against people who lack the maturity to behave collegially. -- Dancing space potatoes? You bet! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Friday 14 December 2007 18:44:09 Paul Schmehl wrote: --On December 14, 2007 5:21:02 PM -0800 Brian [EMAIL PROTECTED] wrote: Information does indeed need to be gathered, and while even the ports list will only grab a small percentage of FreeBSD users, other options would likely grab a lot less. Plus, most of the users here are knowledgeable enough to give decent input. For those of you that don't like change may I suggest the book that led to http://www.whomovedmycheese.com/. It is really in all of our best interest to have the product evolve, the alternative is much worse. This really is getting quite irritating. Not one person on this list has *ever* said they don't want to entertain new ideas for ports. Not one person on this list has said they don't like change. *All* of the complaints have been along the lines of go write some code and stop filling up this list with posts. And that is *precisely* the point. Yet the proponents of the Aryeh bandwagon keep throwing up this straw man that those of us who have tired of the useless back and forth are refusing to listen and uninterested in change, when *nothing* could be further from the truth. ports@ is *not* a development list. Its purpose is to provide news about ports, discuss problems with ports, get advice on porting and so forth. Or, to quote its charter, Discussions concerning FreeBSD's “ports collection” (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected. Get that? Strictly technical. How do you feel about the present design or what don't you like about the present design or if you could change something about ports, what would it be are *not* appropriate discussions for this list. It's time to move this discussion to some place where those that *care* about coding and/or redesigning the ports system can participate and discuss code and return this list to its original purpose. The only FreeBSD list that would be appropriate (if that - it's not really) would be arch, which is for architecture and design discussions. This thread is a design discussion and does not belong here. Please move it to a more appropriate place and leave this list alone. Ask the FreeBSD maintainers to create a new list ports-design@ if you like, but please stop the discussions here. They are inappropriate for this list. And stop lying about the motivations of the many talented people who have asked, politely and otherwise, to stop. I think you have been very politely asked to stop highjacking perfectly legitimate discussion by trolling. If you do not want to contribute positively please use your delete key. In accordance with the charter you describe please make some technical contributions in accordance with the charter. I have already indicated the dangers of loss of credibility that follows from any autocratic assumptions that any one individual is entitled to be prescriptive. I do not think you are entitled to assume that your side of the argument has a monopoly of talent. IMHO we can all do without incessant hectoring, lecturing and bullying and more collegially expressed contributions on topic. This thread is entitled The limits of the Ports System not Why we should not discuss the limts of the ports system. If you have nothing to say on topic then please be humble and keep quiet Thank you ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Fri, Dec 14, 2007 at 10:34:06PM -0500, Yoshihiro Ota wrote: On Thu, 13 Dec 2007 21:58:57 +0100 Erik Trulsson [EMAIL PROTECTED] wrote: One shortcoming is the lack of locking making parallell builds a bit unsafe. If you try to build both port A and port B at the same time, and both A and B depends (directly or indirectly) on port C which is not installed, then you can esily end up having two processes both trying to build C at the same time. This usually confuses both builds very badly making them fail. I also don't think there is any locking on /var/db/pkg making possibly somewhat unsafe trying to register the installation of two ports/packages at the same time. I have never noticed any actual problems with this though. Some sort of locking, making parallel builds safe, should be possible to add to the ports system without doing any sweeping changes. (I did look briefly at the makefiles, but did not find any obvious place to put the locking. I probably just did not look hard enough.) The ports system is to install a new port. It won't be easy to accomplish what you suggest. For example, dependencies are checked one at a time. So, even if you want to run multiple processes on LIB_DEPENDS, there is no easy way to control CPU load. What I suggested should not present any major difficulties. I did not propose automatic parallelization, or anything that needs to control CPU load in way. What I wanted is just support for manual execution of two parallel port builds. E.g. I want to be able to write 'cd /usr/ports/x11/gnome2 ; make install' in one virtual terminal and then, while the first command is running and installing all kinds of dependent ports, to able to switch to another terminal and write 'cd /usr/ports/x11/kde3 ; make install' without having to worry about the fact that some ports (like x11/xorg-libraries) will be needed by both builds. (Assume that I have already done a 'make config-recursive' for both gnome2 and kde3.) Currently doing the above will not work reliably. All that should be needed to make it work reliably is to add some kind of locking so that the ports system will not try to build a port if a build of that particular port is already in progress. (I suspect that using lockf(1) at appropriate places in /usr/ports/Mk/bsd.port.mk would be sufficient, but there are almost certainly a bunch of details and corner-cases that need to be considered.) It is a better idea for other ports UPGRADE utilities to take care of your suggestions. Indeed, I have been developing such utility myself. If you want to try, I can give out for testing. There are 2 known issues with my tool, yet: 1. no good way to run 'make config', yet, and 2. even if less LIB_DEPENDS are required due to less selected OPTIONS, my tool does not fully eliminate these dependencies. Hiro -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Friday 14 December 2007 14:20:24 Remko Lodder wrote: David Southwell wrote: On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. These threads have gone far enough, please consider taking this off the FreeBSD mailinglists and discuss this privately. The majority does not like the current ideas and want to see something usefull first. People like Aryeh and David are not really persons that one would see as the persons generating the ports-infrastructure-ng till they have code. If you both keep pissing off people that have a fair share in the ports collection already, please do it by other means, dont crowd the mailinglists with it. Your ideas might be perfect in your world but they aint in ours (till you have shown working code). This world (the ports mailing list) is our world as much as it is your world. Think about collegial coexistence or use the delete key. Otherwise please stay on topic and stop trolling. This thread is about the limitations of ports system not Why we should not talk about trhe limitations of the Ports System. 1. Stay on topic 2. Start a separate thread if you want - I am sure there will be those who would like to discuss why the limitations of the ports system should not be discussed. 3. Otherwise please make some technical responses to the thread. Thank you ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Aryeh M. Friedman wrote: Your correct that there are 2 seperate issues at play here but there is a common solution (and to be honest I have yet to see any feature/issue discussed in any of the re-engineering threads that doesn't at least become more manageable under this general design concept I am working under) I hate to keep referring to Miller97 but I think it highlights (directly or indirectly) every single issue that has been discussed while a little off topic (and slightly self serving) there is a good explanation of the general idea behind what I have in mind in the cook tutorial (I am the author thus it is self-serving) http://miller.emu.id.au/pmiller/software/cook/cook-2.30.tut.pdf.. In the the specific case of parallel builds once we pre-scan the DAG it is trivial to do a *FULL* DFS on it and just say for any time two ports are not in the same DFS generated subtree in respect to some root target (can be recursive) they can be build in parallel. Locking is also trivial now that the decision on ordering is made by the ports system and not indivual ports makefiles. (the indivual make files are still needed to build the port but should not and by definition can not contain knowledge about their depends). Side note the more we discuss this the more obvious it becomes to me it has to be in some OO lang and since C++ is the only one in the base system it kind of forces C++ to be the implementation lang. ...removing completely unnecessary CC list... Let me get this straight. You've been on this list for around 3 months, you do not maintain any ports, and about the only threads you've been involved in related to redesigning the ports? Please.. You really have no idea how complex a system you are attempting to engineer. I shouldn't even say attempting, because I have yet to see any code, ideas for code, or even talk of what language it will be in. (mind you, I haven't went back through the 3-4 threads on this same topic you've participated in) Please take this thread elseware, there is no need to make it public until you have something to show the masses. Regards, Frank Laszlo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Saturday 15 December 2007 08:04:31 Frank J. Laszlo wrote: Aryeh M. Friedman wrote: Your correct that there are 2 seperate issues at play here but there is a common solution (and to be honest I have yet to see any feature/issue discussed in any of the re-engineering threads that doesn't at least become more manageable under this general design concept I am working under) I hate to keep referring to Miller97 but I think it highlights (directly or indirectly) every single issue that has been discussed while a little off topic (and slightly self serving) there is a good explanation of the general idea behind what I have in mind in the cook tutorial (I am the author thus it is self-serving) http://miller.emu.id.au/pmiller/software/cook/cook-2.30.tut.pdf.. In the the specific case of parallel builds once we pre-scan the DAG it is trivial to do a *FULL* DFS on it and just say for any time two ports are not in the same DFS generated subtree in respect to some root target (can be recursive) they can be build in parallel. Locking is also trivial now that the decision on ordering is made by the ports system and not indivual ports makefiles. (the indivual make files are still needed to build the port but should not and by definition can not contain knowledge about their depends). Side note the more we discuss this the more obvious it becomes to me it has to be in some OO lang and since C++ is the only one in the base system it kind of forces C++ to be the implementation lang. ...removing completely unnecessary CC list... Let me get this straight. You've been on this list for around 3 months, you do not maintain any ports, and about the only threads you've been involved in related to redesigning the ports? Please.. You really have no idea how complex a system you are attempting to engineer. I shouldn't even say attempting, because I have yet to see any code, ideas for code, or even talk of what language it will be in. (mind you, I haven't went back through the 3-4 threads on this same topic you've participated in) Please take this thread elseware, there is no need to make it public until you have something to show the masses. Regards, Frank Laszlo And get this I have been around the computer world using *nix long before freebsd came along. That does not mean what I say today deserves to be judged other than on its face value. However what over 40 years in IT has encouraged me to think that those who invite people to judge a book by its cover have either not read the book or can't be bothered to do so. I am sure you have a lot of knowledge and experience but I doubt whether your collegiality is more attractive than your sense of humour. I recall you once said: remember sometimes my jokes are crude judging by your contributions to this thread am I not entitled to wonder if your assessment of your jokes is also applicable to your general standard of reasoning? Now please take note; 1. This thread is entitled Limitation of Ports System. Please stay on topic. 2. If you want people to take you seriously either post some technical information relevant to the topic that gains you some credibility or press the delete key and keep quiet. 3. Please stop trolling. 4. You could start a thread Why we should not discuss the limitations of Port System and keep your contributions on topic there. I can assure you that I will not be trying to highjack that dialogue. Yours David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
David Southwell wrote: And get this I have been around the computer world using *nix long before freebsd came along. That does not mean what I say today deserves to be judged other than on its face value. However what over 40 years in IT has encouraged me to think that those who invite people to judge a book by its cover have either not read the book or can't be bothered to do so. I am sure you have a lot of knowledge and experience but I doubt whether your collegiality is more attractive than your sense of humour. I recall you once said: remember sometimes my jokes are crude judging by your contributions to this thread am I not entitled to wonder if your assessment of your jokes is also applicable to your general standard of reasoning? I am making no jokes. Also note that I was not speaking to you, so why do you get in the middle of every one elses business? Now please take note; 1. This thread is entitled Limitation of Ports System. Please stay on topic. I was not the person who went off topic, perhaps you should read back to the beginning on this thread where Aryeh began to bring his project back into this topic. 2. If you want people to take you seriously either post some technical information relevant to the topic that gains you some credibility or press the delete key and keep quiet. I have no need to gain credibility, those who know me know exactly how credible I am. those who dont, I could care less what they think. This includes you sir. 3. Please stop trolling. I am not trolling, If I didnt know any better, I'd say that you are the one trolling. 4. You could start a thread Why we should not discuss the limitations of Port System and keep your contributions on topic there. I can assure you that I will not be trying to highjack that dialogue. Thats rediculous, certainly your 40+ years in IT would have discovered this long before posting such useless comments. I rarely post on -ports anymore, due to the lack of order and respect for those who actually DO SOMETHING, and not just bitch and moan about things that should be done. This thread is useless, as there is no actual solutions attached.. If you want to bitch and moan about how things should get done on freebsd, then move it to -chat, theres plenty of trolls to feed there. -Frank ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Saturday 15 December 2007 10:41:14 Frank J. Laszlo wrote: David Southwell wrote: And get this I have been around the computer world using *nix long before freebsd came along. That does not mean what I say today deserves to be judged other than on its face value. However what over 40 years in IT has encouraged me to think that those who invite people to judge a book by its cover have either not read the book or can't be bothered to do so. I am sure you have a lot of knowledge and experience but I doubt whether your collegiality is more attractive than your sense of humour. I recall you once said: remember sometimes my jokes are crude judging by your contributions to this thread am I not entitled to wonder if your assessment of your jokes is also applicable to your general standard of reasoning? I am making no jokes. Also note that I was not speaking to you, so why do you get in the middle of every one elses business? What you say on this list is everyone's business and those who do not post collegially may expect to be reminded of its value. Now please take note; 1. This thread is entitled Limitation of Ports System. Please stay on topic. I was not the person who went off topic, perhaps you should read back to the beginning on this thread where Aryeh began to bring his project back into this topic. 2. If you want people to take you seriously either post some technical information relevant to the topic that gains you some credibility or press the delete key and keep quiet. I have no need to gain credibility, those who know me know exactly how credible I am. those who dont, I could care less what they think. This includes you sir. IMHO credibility is gained by treating individuals with respect even when one disagrees with their point of view. In a technical list such as ports@ one is entitled to expect a technical response not invalid arguments ad personam. 3. Please stop trolling. I am not trolling, If I didnt know any better, I'd say that you are the one trolling. Prove it. Either make a technical contribution or use the delete key. 4. You could start a thread Why we should not discuss the limitations of Port System and keep your contributions on topic there. I can assure you that I will not be trying to highjack that dialogue. Thats rediculous, certainly your 40+ years in IT would have discovered this long before posting such useless comments. My intention is not to offend but to draw attention to the need to remain on topic and not to argue ad personam. I rarely post on -ports anymore, due to the lack of order and respect for those who actually DO SOMETHING, and not just bitch and moan about things that should be done. This thread is useless, as there is no actual solutions attached.. If you want to bitch and moan about how things should get done on freebsd, then move it to -chat, theres plenty of trolls to feed there. If the thread is useless why are you wasting your time posting to it? In the face of these statement Iis it not reasonable to ask if you posting for kicks? David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Frank J. Laszlo wrote: I rarely post on -ports anymore, due to the lack of order and respect for those who actually DO SOMETHING, and not just bitch and moan about things that should be done. I remember it was only a few short years ago that ports@ was completely inundated by receiving every PR that was ports related. Now these PR's are thankfully sent to a different group, I think it is [EMAIL PROTECTED] (I admit complete ignorance of the history behind why this was done!) Before then, I found ports@ completely unusable. Now I am finding it to be a very interesting and very, very useful mailing list. Sometimes I happen to have the answer to someone else's issue. And very often, when I have a problem, some kind person has a good answer for me! Anyway, if you are going to have a mailing list like this one, and if it is going to be of any use at all, then you must simply accept bitching and moaning as part of the process. If you try to silence what you perceive to be bitching and moaning, more than likely you are going to stop what could be potentially very useful discussions. In particular, if there isn't some discussion as to why the status quo is screwed up, then the status quo IS screwed up, and dissent is being inappropriately squashed. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Frank J. Laszlo wrote: I rarely post on -ports anymore, due to the lack of order and respect for those who actually DO SOMETHING, and not just bitch and moan about things that should be done. Let me also make another point related to this sentence. While obviously there should be respect for those who actually do something, there also very much needs to be respect for those who DON'T do something. FreeBSD's goal ultimately is to serve the community - as it says in big letters on the main web page The Power to Serve. Not everyone has time or talent enough to make an effective contribution, but even those who simply use the product must be seen as important members of the FreeBSD community. As such, requests or complaints should be taken seriously. It is OK to argue that they are asking too much, or that we cannot provide for their request, but it is never OK to simply tell them to shut up. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 you do not maintain any ports Incorrect I have one that is currently officially pending in the backlog created by the freeze (the PR is sitting their waiting). Also as soon that port is done and any errors I may of made as it being my first port I have 2 more to be added and on a fairly regular basis see adding to that list. - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZEcIzIOMjAek4JIRAhhiAJ9niZH5yha4BRsz2IzxBHv9c4x0ZwCeLRfY vLsD+SpFSAXGimYXYQbtd34= =jMcT -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Friday 14 Dec 2007, [EMAIL PROTECTED] wrote: I was not planning to skimp on the requirements at all but the test case is xorg. A far better test case, IMHO, would be to run a similar build to the pointyhat cluster if you're serious about *replacing* the ports system. Unless a new system can do this, as well as being able to produce packages for a centralised port build system for multiple machines (yes, you can do this with NFS and a little thought), the metaphor snowball in hell springs to mind. The job you've given yourself is an elephant. I'll leave it up to others to decide if it's white or just too large to eat on your own all at once. Furthermore, if said elephant isn't consumed in its entirety, expect some resistance to your proof of concept code from some unexpected sources since the ports system isn't just the package management system some people seem to think it is. Looking at all this from a user's perspective is fine and dandy until you have a release to do. The ports are tied into bits of the base system in various ways, for example, make release or USE_OPENSSL=base. The current system, although appearing to drip with legacy methods and what look like arcane rituals to appease the make god (until you understand how it all fits together), is very powerful - perhaps more so than any other package managment system I've ever used - and is structured to work for end users, the release engineering and ports management teams. I suspect this is why so many @FreeBSD.org replies were negative. I don't wish to rock the boat and start another 8 kids 1 toy discourse and there is certainly no malice or insult intended, but the ports system is so much more than getting X installed on a desktop box. First and foremost, release engineering depends on it. Change can be good, but always remember the alternate definition of progress: Taking the best of what you have. And ruining it. -- Matt Dawson. [EMAIL PROTECTED] MTD15-RIPE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Dawson wrote: On Friday 14 Dec 2007, [EMAIL PROTECTED] wrote: I was not planning to skimp on the requirements at all but the test case is xorg. A far better test case, IMHO, would be to run a similar build to the pointyhat cluster if you're serious about *replacing* the ports system. Unless a new system can do this, as well as being able to produce packages for a centralised port build system for multiple machines (yes, you can do this with NFS and a little thought), the metaphor snowball in hell springs to mind. In the parlance of testing I consider xorg to be a large but basically a unit test. It has the following advantages: 1. Just enough external depends to not make it completely trivial (thus ideal for a unit style test) 2. Certain ports with in the system behave different depending on the order stuff is built in thus this serves as a good proof that DAG scanning is working on a non-trivial DAG 3. Unlike attempting to build the entire ports collection it is a relatively stable target (again an other key requirement for a unit test) Once xorg works correctly I will consider the new system to be alpha for the purposes of scaling it up to a static build of the whole ports system (alpha2) and finally the beta is doing it against a non-static ports system (i.e. having the two systems track each other). So when I said release I did not mean entery into production I just meant complete enough to allow non-core developer use. The idea is except for handling special cases as gracefully as possible the system is complete after xorg and special cases is where it becomes larger then what a small team of 1 or 2 people can handle. This does not preclude refactoring on behalf of the core team to make it so there as few special cases as possible. The job you've given yourself is an elephant. I'll leave it up to others to decide if it's white or just too large to eat on your own all at once. Furthermore, if said elephant isn't consumed in its entirety, expect some resistance to your proof of concept code from some unexpected sources since the ports system isn't just the package management system some people seem to think it is. Proof of concept is a little stronger then how I would describe it. Looking at all this from a user's perspective is fine and dandy until you have a release to do. The ports are tied into bits of the base system in various ways, for example, make release or USE_OPENSSL=base. The current system, although appearing to drip with legacy methods and what look like arcane rituals to appease the make god (until you understand how it all fits together), is very powerful - perhaps more so than any other package managment system I've ever used - and is structured to work for end users, the release engineering and ports management teams. I suspect this is why so many @FreeBSD.org replies were negative. The general model I have in mind more then enough accounts for this interplay... but this entire discussion is getting ahead of the project we still don't have a clear idea of the project scope. I don't wish to rock the boat and start another 8 kids 1 toy discourse and there is certainly no malice or insult intended, but the ports system is so much more than getting X installed on a desktop box. First and foremost, release engineering depends on it. Change can be good, but always remember the alternate definition of progress: Taking the best of what you have. And ruining it. I understand this completely (one reason I am doing this is I am working on a commerical OS that will need near equivelent functionality and this is the perfect way to prototype the concepts without creating a all or nothing risk [i.e. FreeBSD can always fall back on the current system where is the OS I am working for all intensive purposes will be stuck with what ever solution is implemented on it]). X is really nothing more then a large scale unit test. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYmbMzIOMjAek4JIRAtiwAJ9EsK2iBDmwqlr2DoZrJzedqwjeXACgpiGk LVPJXVFIZgwYWd0XBt7s0zo= =uqaP -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
--On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. Please repeat that one hundred times until it gets through. No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RW wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def There are multiple ways to handle the effects of 345 on def... only one of them is to automatically apply it the other two are def can ignore it by default or make it suer settable -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYucdzIOMjAek4JIRAgBQAJ9NZEM3EoOieFprT+f4LUe/g3GqiQCfT7N6 lW3o2lmL+g5FZk0oUsSZpxA= =nzu2 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. Please repeat that one hundred times until it gets through. No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. I refuse to debate people with ear plugs on... if you want an honest debate please do so honestly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYufyzIOMjAek4JIRAjWuAKCjBekW4+ysIJEBHZ5HShiIbzrRkwCcDo5H WVBI+0rgJDXcTG3Wpeu+90Y= =rsQy -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Aryeh M. Friedman wrote: RW wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def There are multiple ways to handle the effects of 345 on def... only one of them is to automatically apply it the other two are def can ignore it by default or make it suer settable Other than the automatic caching apsect, how would this be any different from what we already have with ports-mgmt/portconf? Currently, if you want a knob to apply to all ports, you wildcard the knob in your ports.conf file. If you want the same knob defined differently depending on port name, you define it per port. -- Skip ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Skip Ford wrote: Aryeh M. Friedman wrote: RW wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def There are multiple ways to handle the effects of 345 on def... only one of them is to automatically apply it the other two are def can ignore it by default or make it suer settable Other than the automatic caching apsect, how would this be any different from what we already have with ports-mgmt/portconf? Currently, if you want a knob to apply to all ports, you wildcard the knob in your ports.conf file. If you want the same knob defined differently depending on port name, you define it per port. Often it is not possible to know if you want a knob until seeing it in context... see my reply to RW for more info -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYvT/zIOMjAek4JIRAul8AJ9dSWyYDGJTOh1d9ffBrPtBDsbKOwCgirF1 003NMaY15t0i3H2950Yt3Lw= =R/xP -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Aryeh M. Friedman wrote: Remko Lodder wrote: David Southwell wrote: On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. These threads have gone far enough, please consider taking this off the FreeBSD mailinglists and discuss this privately. The majority does not like the current ideas and want to see something usefull first. People like Aryeh and David are not really persons that one would see as the persons generating the ports-infrastructure-ng till they have code. If you both keep pissing off people that have a fair share in the ports collection already, please do it by other means, dont crowd the mailinglists with it. Your ideas might be perfect in your world but they aint in ours (till you have shown working code). So please stfu till you have some code and be done with it DOT. Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... why is it that everyone who sees the whole concept as being negative has offered no input what so ever about what should be done (even saying the current system is fine is useful to us) simply because we have seen it failing a lot of times. Please take this offlist,discuss this and generate a nice PoC, then get back to us, till that time, DONT bother the ports list with it or any other list. You are the single reason for a HIGH S/N ration on MOST lists I am subscribed to that is a REALLY -BAD- thing. You Simply dont understand the way it works here and I can understand that till a certain point of view; take the advise; discuss it elsewhere, and get back with working code (yeah I repeat it twice because nobody seems to get through to you, and MANY people tried it already). -- /\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
David Southwell wrote: On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. These threads have gone far enough, please consider taking this off the FreeBSD mailinglists and discuss this privately. The majority does not like the current ideas and want to see something usefull first. People like Aryeh and David are not really persons that one would see as the persons generating the ports-infrastructure-ng till they have code. If you both keep pissing off people that have a fair share in the ports collection already, please do it by other means, dont crowd the mailinglists with it. Your ideas might be perfect in your world but they aint in ours (till you have shown working code). So please stfu till you have some code and be done with it DOT. -- /\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remko Lodder wrote: David Southwell wrote: On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. These threads have gone far enough, please consider taking this off the FreeBSD mailinglists and discuss this privately. The majority does not like the current ideas and want to see something usefull first. People like Aryeh and David are not really persons that one would see as the persons generating the ports-infrastructure-ng till they have code. If you both keep pissing off people that have a fair share in the ports collection already, please do it by other means, dont crowd the mailinglists with it. Your ideas might be perfect in your world but they aint in ours (till you have shown working code). So please stfu till you have some code and be done with it DOT. Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... why is it that everyone who sees the whole concept as being negative has offered no input what so ever about what should be done (even saying the current system is fine is useful to us) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYwOjzIOMjAek4JIRAs8qAJ9Xa0loqoVr3dlKIT5AcOt5m6YKXACdE8QG 4ZPSX/xHgiiLW72pUPNW/W0= =KW47 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remko Lodder wrote: Aryeh M. Friedman wrote: Remko Lodder wrote: David Southwell wrote: On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. These threads have gone far enough, please consider taking this off the FreeBSD mailinglists and discuss this privately. The majority does not like the current ideas and want to see something usefull first. People like Aryeh and David are not really persons that one would see as the persons generating the ports-infrastructure-ng till they have code. If you both keep pissing off people that have a fair share in the ports collection already, please do it by other means, dont crowd the mailinglists with it. Your ideas might be perfect in your world but they aint in ours (till you have shown working code). So please stfu till you have some code and be done with it DOT. Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... why is it that everyone who sees the whole concept as being negative has offered no input what so ever about what should be done (even saying the current system is fine is useful to us) simply because we have seen it failing a lot of times. Please take this offlist,discuss this and generate a nice PoC, then get back to us, till that time, DONT bother the ports list with it or any other list. You are the single reason for a HIGH S/N ration on MOST lists I am subscribed to that is a REALLY -BAD- thing. Perhaps one reason it has failed is because there was not a wide enough front end effort to decide what was really needed vs. what some individual thought was needed... as to the s/n thing there would be lot less if you actually debated on the technical merits of the proposal and not the meta discussion of does something belong here or list b or where ever... unless you think community input is completely pointless I invite you to suggest an other medium that allows for it without making is semi-obscure and hard to find. You Simply dont understand the way it works here and I can understand that till a certain point of view; take the advise; discuss it elsewhere, and get back with working code (yeah I repeat it twice because nobody seems to get through to you, and MANY people tried it already). Oh I hear the message loud and clear
Re: Limitations of Ports System
Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remko Lodder wrote: Aryeh M. Friedman wrote: Remko Lodder wrote: David Southwell wrote: On Friday 14 December 2007 08:08:54 Paul Schmehl wrote: --On Friday, December 14, 2007 12:19:06 + RW [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 22:34:58 -0500 Aryeh M. Friedman [EMAIL PROTECTED] wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on abc, but causes lock-ups on def SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. I do wish you could acquire the maturity to distinguish between the advantages that could come arguing your case clearly and collegially and the disadvantages that acrue from being personally antagonistic towards someone with whose analysis you happen to disagree. For me when someone becomes abusive they destroy their own credibility and get to sound as though they believe their opinions antitle them to be hateful and that their own views are somehow godgiven. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. IMHO Shouting make you less rather than more credible. \Please repeat that one hundred times until it gets through. Endless repetition does not add strength to analysis!! No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. IMHO You would sound more credible if you used the IMHO a bit more!! You might also gain some respect if you followed your own advice. Make suggestions for others to consider - do not decide, in advance, they are thick skulled if they do not agree with you!! It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. IMHO Shouting, hectoring and lecturing does not add weight to anyones point of view. These threads have gone far enough, please consider taking this off the FreeBSD mailinglists and discuss this privately. The majority does not like the current ideas and want to see something usefull first. People like Aryeh and David are not really persons that one would see as the persons generating the ports-infrastructure-ng till they have code. If you both keep pissing off people that have a fair share in the ports collection already, please do it by other means, dont crowd the mailinglists with it. Your ideas might be perfect in your world but they aint in ours (till you have shown working code). So please stfu till you have some code and be done with it DOT. Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... why is it that everyone who sees the whole concept as being negative has offered no input what so ever about what should be done (even saying the current system is fine is useful to us) simply because we have seen it failing a lot of times. Please take this offlist,discuss this and generate a nice PoC, then get back to us, till that time, DONT bother the ports list with it or any other list. You are the single reason for a HIGH S/N ration on MOST lists I am subscribed to that is a REALLY -BAD- thing. Perhaps one reason it has failed is because there was not a wide enough front end effort to decide what was really needed vs. what some individual thought was needed... as to the s/n thing there would be lot less if you actually debated on the technical merits of the proposal and not the meta discussion of does something belong here or list b or where ever... unless you think community input is completely pointless I invite you to suggest an other medium that allows for it without making is semi-obscure and hard to find. You Simply dont understand the way it works here and I can understand that till a certain point of view; take
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 1. Make plan. 2. Ask limited group for sanity check. 3. Code, code code. Go back to 2. if necessary. Continue to 4. when done. 4. Ask larger group for sanity check and testing. Go back to 3. if necessary. Continue to 5. when done. 5. Release. We're still at 1., and while I think that the problem to 1. can be established and thought out via email, perhaps the stakeholders need to brainstorm and research more about 1. on the lists, as this topic has been brought up a few times already (see the ports@ and hackers@ archives in particular). We (at least I) have done a good amount of background research but several key issues where not answered thus my public questions. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYxyKzIOMjAek4JIRAohzAJ93pnk01isO8YJ4wvXowkvG56DkdwCgmdgS gsx4EyT8gJka/10p1Zdjtlc= =rUS6 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Aryeh M. Friedman wrote: Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... And that's fine if that's how you prefer to work, but everyone's point is that it has nothing to do with the current ports system at all so the talk doesn't belong on a mailing list dedicated to the current ports system. It's just noise here. Research for a new system from ports@ users belongs on a list dedicated to the new system. why is it that everyone who sees the whole concept as being negative has offered no input what so ever about what should be done (even saying the current system is fine is useful to us) You've been told over and over what should be done. You need a ports-ng wiki (or whatever you want to call your new system) and/or your own mailing list. Posting a single message occasionally on ports@ to point others to a new system in the works is perfectly fine, but using a mailing list dedicated to one system to develop another competing system isn't. If you need research from ports@ readers, you post a message pointing them elsewhere, you don't do it in a way that floods this list with 100+ messages. You've been given lots of sound advice on how to proceed and you've listened to none of it. You haven't heard what anyone has said thus far. Just start a wiki already like you've been told to do by those who already know exactly what they're doing, and aren't still trying to figure out how to figure out what it is they might want to do someday. -- Skip ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Remko Lodder wrote: You Simply dont understand the way it works here and I can understand that till a certain point of view; take the advise; discuss it elsewhere, and get back with working code (yeah I repeat it twice because nobody seems to get through to you, and MANY people tried it already). Oh I hear the message loud and clear and just happen to not agree with the thinking behind it. Namely ivory tower development has its place but not here. This is my thinking. I think what Aryeh is doing here is fine. But perhaps Aryeh and David need to stop rising to the bait when someone tells them they are wrong. I understand them replying up until now, because I can see that silence might be interpreted as their acquiescence. But I think to reply to naysayers now will only add much more noise. Both sides have made their points loud and clear, and the points don't need repetition. Remko: this thread has generated interesting discussions, clearly relevant to ports. If you don't like the discussions, simply press the delete key or don't reply. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Skip Ford wrote: Aryeh M. Friedman wrote: Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... And that's fine if that's how you prefer to work, but everyone's point is that it has nothing to do with the current ports system at all so the talk doesn't belong on a mailing list dedicated to the current ports system. It's just noise here. Research for a new system from ports@ users belongs on a list dedicated to the new system. First of all not everyone has said a number of people (not including me) have said it is the proper place one thing is clear though there really is no proper mailing lists and wiki's have some problems covered below why is it that everyone who sees the whole concept as being negative has offered no input what so ever about what should be done (even saying the current system is fine is useful to us) You've been told over and over what should be done. You need a ports-ng wiki (or whatever you want to call your new system) and/or your own mailing list. Posting a single message occasionally on ports@ to point others to a new system in the works is perfectly fine, but using a mailing list dedicated to one system to develop another competing system isn't. If you need research from ports@ readers, you post a message pointing them elsewhere, you don't do it in a way that floods this list with 100+ messages. The simpler case is the seperate mailing list once there is a good idea of what is needed then moving to such a forum makes a great amount of sense and the 3 volunteers (including me) that have made firm commitments to work on the project do just this... but in the early design phases (deciding if the project is needed, the scope and gathering top level requirments/features) public input is critical and taking stuff out of a well established forum reduces the amount of useful input... btw we are basically somewhere between scope and top level requirement gathering (the internal mailing list is attempting to settle on a final scope statement so we can move to the final truly public phase which is systematic gathering of requirements) The wiki poses some issues due to the medium of wiki's vs. the medium of mail... the first of these issues is wiki's are terrible for discusssions and a very lively on topic discussion is the best way to iron out the 3 public phases... what wiki's are very good at is recording decisions and we defently plan to use a wiki for this... but besides for the project should be done not enough decisions have been made to justify a record of them currently, as soon as the scope is decided internally we will produce some docs that will justify a wiki (and since they are still in the public phases I will post them here for discussion purposes)... as soon the second set of docs (top level requirements) is produced all the work will occur privately except for one final post that details the conceptual model for public comment You've been given lots of sound advice on how to proceed and you've listened to none of it. You haven't heard what anyone has said thus far. Just start a wiki already like you've been told to do by those who already know exactly what they're doing, and aren't still trying to figure out how to figure out what it is they might want to do someday. On techinical issues I have heard almost all of it and have substantially revised my mental conceptual model based on it. But as far as what should be public and what should be private good software engineering not only says the minority is wrong but I am using what is considered the industry standard method (as much as possible when it is not f2f). If the industry standard doesn't agree with FreeBSD's method then it does make sense to check if the FreeBSD model can not be improved in light of newer data. In sort the main metadebate is on cultural differences and that is sad because culture should have nothing to do with the tech aspects. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYxvQzIOMjAek4JIRAsRSAJ9YBTglveSohfNWAaKdvG3JrKUq7gCfUI3H v65HbjHbwZs+JryHeOqXOr4= =353C -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Kirkwood wrote: Skip Ford wrote: Aryeh M. Friedman wrote: Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... And that's fine if that's how you prefer to work, but everyone's point is that it has nothing to do with the current ports system at all so the talk doesn't belong on a mailing list dedicated to the current ports system. It's just noise here. Research for a new system from ports@ users belongs on a list dedicated to the new system. That is a little unfair IMHO - Aryeh has to gather information from those who use the current system, and @ports is clearly the place for that! Now he may listen to all, some or none of the points of view he receives... and that may well determine the success or otherwise of his ports-ng process - but I don't think he is doing anything wrong. I agree that a new list (ports-ng or similar) for this would be a good thing to start *soon*, so that those folks (probably from *this* list) who are interested can see what is happening and maybe help if they like! There is already an informal private one but until scope and some top level features are decided the vast majority of discussion will be on - -ports@ and as soon they are very little should be. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYyO+zIOMjAek4JIRAv4HAJ9pdPTWAYuEYsrfy4yNDL5+ZW3FeACeLfco JWBitNl/q0ntsb9bQhOm5L8= =Z2I6 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Skip Ford wrote: Aryeh M. Friedman wrote: Developing in a vacuum is a recipe for disaster we are making fairly good progress believe it or not I only see an other 1 or 2 threads being needed before actual coding starts, *BUT* producing a system no one wants is pointless thus it is wise to gather as much input as possible... And that's fine if that's how you prefer to work, but everyone's point is that it has nothing to do with the current ports system at all so the talk doesn't belong on a mailing list dedicated to the current ports system. It's just noise here. Research for a new system from ports@ users belongs on a list dedicated to the new system. That is a little unfair IMHO - Aryeh has to gather information from those who use the current system, and @ports is clearly the place for that! Now he may listen to all, some or none of the points of view he receives... and that may well determine the success or otherwise of his ports-ng process - but I don't think he is doing anything wrong. I agree that a new list (ports-ng or similar) for this would be a good thing to start *soon*, so that those folks (probably from *this* list) who are interested can see what is happening and maybe help if they like! Cheers Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Mark Kirkwood wrote: That is a little unfair IMHO - Aryeh has to gather information from those who use the current system, and @ports is clearly the place for that! Now he may listen to all, some or none of the points of view he receives... and that may well determine the success or otherwise of his ports-ng process - but I don't think he is doing anything wrong. I agree that a new list (ports-ng or similar) for this would be a good thing to start *soon*, so that those folks (probably from *this* list) who are interested can see what is happening and maybe help if they like! Cheers Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] Information does indeed need to be gathered, and while even the ports list will only grab a small percentage of FreeBSD users, other options would likely grab a lot less. Plus, most of the users here are knowledgeable enough to give decent input. For those of you that don't like change may I suggest the book that led to http://www.whomovedmycheese.com/. It is really in all of our best interest to have the product evolve, the alternative is much worse. Brian ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
At 10:08 AM -0600 12/14/07, Paul Schmehl wrote: SInce I've already killfiled Aryeh, I guess we should all killfile you, too. -- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
--On December 14, 2007 5:21:02 PM -0800 Brian [EMAIL PROTECTED] wrote: Information does indeed need to be gathered, and while even the ports list will only grab a small percentage of FreeBSD users, other options would likely grab a lot less. Plus, most of the users here are knowledgeable enough to give decent input. For those of you that don't like change may I suggest the book that led to http://www.whomovedmycheese.com/. It is really in all of our best interest to have the product evolve, the alternative is much worse. This really is getting quite irritating. Not one person on this list has *ever* said they don't want to entertain new ideas for ports. Not one person on this list has said they don't like change. *All* of the complaints have been along the lines of go write some code and stop filling up this list with posts. And that is *precisely* the point. Yet the proponents of the Aryeh bandwagon keep throwing up this straw man that those of us who have tired of the useless back and forth are refusing to listen and uninterested in change, when *nothing* could be further from the truth. ports@ is *not* a development list. Its purpose is to provide news about ports, discuss problems with ports, get advice on porting and so forth. Or, to quote its charter, Discussions concerning FreeBSD's “ports collection” (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected. Get that? Strictly technical. How do you feel about the present design or what don't you like about the present design or if you could change something about ports, what would it be are *not* appropriate discussions for this list. It's time to move this discussion to some place where those that *care* about coding and/or redesigning the ports system can participate and discuss code and return this list to its original purpose. The only FreeBSD list that would be appropriate (if that - it's not really) would be arch, which is for architecture and design discussions. This thread is a design discussion and does not belong here. Please move it to a more appropriate place and leave this list alone. Ask the FreeBSD maintainers to create a new list ports-design@ if you like, but please stop the discussions here. They are inappropriate for this list. And stop lying about the motivations of the many talented people who have asked, politely and otherwise, to stop. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Fri, Dec 14, 2007 at 07:51:14PM -0500, Garance A Drosehn wrote: At 10:08 AM -0600 12/14/07, Paul Schmehl wrote: SInce I've already killfiled Aryeh, I guess we should all killfile you, too. Can we please just stop the meta-thread now and go back to working on all the myriad things that need to be fixed? Thanks. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It is too bad I am in your killfile because you will not get this ;-)
Yet the proponents of the Aryeh bandwagon keep throwing up this
straw man that those of us who have tired of the useless back and
forth are refusing to listen and uninterested in change, when
*nothing* could be further from the truth. ports@ is *not* a
development list. Its purpose is to provide news about ports,
discuss problems with ports, get advice on porting and so forth.
Or, to quote its charter, Discussions concerning FreeBSD's “ports
collection” (/usr/ports), ports infrastructure, and general ports
coordination efforts. This is a technical mailing list for which
strictly technical content is expected.
1. It specifically does not preclude such a discussion
2. If you where willing to have a rational debate vs. this chaos (some
of my supporters may have gone too far but it is only out of
reaction to the complete irrationality of some of those who don't like
the idea... btw I am not accusing anyone one of being against the
general concept of improving stuff just some people have really
stupid ideas {i.e. to me the seem like a recipe for disaster} of the
proper way to gather the information needed to do it right [not at all])
Get that? Strictly technical. How do you feel about the
present design or what don't you like about the present design
or if you could change something about ports, what would it be
are *not* appropriate discussions for this list.
Name a specific aspect of an on topic reply (not debates about the
merits of the idea and/or the process of gathering info) that is not
specifically techinical. By definition I think it is impossible not
to have anything but a purely tech discussion unless your one of these
narrow minded people who thinks that 2+2=4 is techinical but what
is the result of adding two and two is not technical.
It's time to move this discussion to some place where those that
*care* about coding and/or redesigning the ports system can
participate and discuss code and return this list to its original
purpose. The only FreeBSD list that would be appropriate (if that
- it's not really) would be arch, which is for architecture and
design discussions. This thread is a design discussion and does
not belong here. Please move it to a more appropriate place and
leave this list alone. Ask the FreeBSD maintainers to create a new
list ports-design@ if you like, but please stop the discussions
here. They are inappropriate for this list.
As soon the rough design is worked out (which if people would stop
debating pointless stuff and stay on topic would take a week or so)
almost nothing will be discussed on any existing -XXX@ list, the
working group will use it's own list [not sure if it will be public or
private yet], except for occasional progress reports.. just like any
other project (and just like any other project there is a hopefully
brief [compared to the total effort] peroid of public discussion
concerning the general aspects and that is what is happening now on
- [EMAIL PROTECTED])
And stop lying about the motivations of the many talented people
who have asked, politely and otherwise, to stop.
I don't see how anyone ascribed any motive to anyone except for some
opponents of my approach saying I have alternative motives
speaking of that I need to clarify one thing when I said my personal
reasons for doing this is to create a prototype for a commercial
system I am working on I didn't not mean the two projects will be
connected in any shape or form except for sharing some concepts
the commercial version will be in Java for a OS radically diff then
Unix thus almost no code portability is possible also the FreeBSD
stuff will be 100% under the BSD license (note the commercial version
will have open sources also see my company's web site
http://www.flosoft-systems.com for details) the reason for calling
the FreeBSD version a prototype is FreeBSD can always fall back on the
current system but for the commercial stuff due to it's nature there
is no fall back position.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHY0ShzIOMjAek4JIRApRXAJ9yLSVMCxgrogUvNaa0wr2tj8ceMgCeI78p
oI6J7k4VrK7622nSxxS7pmo=
=aCgZ
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
--On December 14, 2007 7:51:14 PM -0500 Garance A Drosehn [EMAIL PROTECTED] wrote: At 10:08 AM -0600 12/14/07, Paul Schmehl wrote: SInce I've already killfiled Aryeh, I guess we should all killfile you, too. Be my guest. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Paul Schmehl wrote: --On December 14, 2007 5:21:02 PM -0800 Brian [EMAIL PROTECTED] wrote: Information does indeed need to be gathered, and while even the ports list will only grab a small percentage of FreeBSD users, other options would likely grab a lot less. Plus, most of the users here are knowledgeable enough to give decent input. For those of you that don't like change may I suggest the book that led to http://www.whomovedmycheese.com/. It is really in all of our best interest to have the product evolve, the alternative is much worse. This really is getting quite irritating. Not one person on this list has *ever* said they don't want to entertain new ideas for ports. Not one person on this list has said they don't like change. *All* of the complaints have been along the lines of go write some code and stop filling up this list with posts. And that is *precisely* the point. Yet the proponents of the Aryeh bandwagon keep throwing up this straw man that those of us who have tired of the useless back and forth are refusing to listen and uninterested in change, when *nothing* could be further from the truth. ports@ is *not* a development list. Its purpose is to provide news about ports, discuss problems with ports, get advice on porting and so forth. Or, to quote its charter, Discussions concerning FreeBSD's “ports collection” (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected. Get that? Strictly technical. How do you feel about the present design or what don't you like about the present design or if you could change something about ports, what would it be are *not* appropriate discussions for this list. You are the first person who has raised any kind of coherent argument as to why perhaps Aryeh shouldn't be asking these questions on [EMAIL PROTECTED] Your argument is based on the interpretation of the phrase strictly technical that appears in the charter, because Aryeh's posts are clearly in line with every other phrase in the charter. Personally I would not agree with your interpretation that Aryeh's posts contradict strictly technical, but then again I have never really thought long and hard about what strictly technical means in this context. Now to your point about straw men, I have refrained from doing as others have done, and have not tried to ascribe motives as to why this particular discussion has so offended people. But the overreaction to Aryeh's posts is definitely a mystery, and I can understand why people are speculating. The idea of a new mailing list: if the discussion about ports design got to overwhelm ports@, then it would become time to create a new mailing list. But up until now, the ports design posts with genuine content (as opposed to the get out of here posts) have been sufficiently few and sufficiently non-disruptive to this mailing list, that I don't think it is worth while to do this. If people simply responded to Aryeh's posts with strictly technical answers, the whole discussion would have been a few posts. I do agree that Aryeh's discussions are not along the lines of port XXX is not working, but I just don't see why both kinds of posting cannot coexist in peaceful harmony, with a split happening only if one set of discussions threatens to overwhelm the other. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Thu, 13 Dec 2007 21:58:57 +0100 Erik Trulsson [EMAIL PROTECTED] wrote: One shortcoming is the lack of locking making parallell builds a bit unsafe. If you try to build both port A and port B at the same time, and both A and B depends (directly or indirectly) on port C which is not installed, then you can esily end up having two processes both trying to build C at the same time. This usually confuses both builds very badly making them fail. I also don't think there is any locking on /var/db/pkg making possibly somewhat unsafe trying to register the installation of two ports/packages at the same time. I have never noticed any actual problems with this though. Some sort of locking, making parallel builds safe, should be possible to add to the ports system without doing any sweeping changes. (I did look briefly at the makefiles, but did not find any obvious place to put the locking. I probably just did not look hard enough.) The ports system is to install a new port. It won't be easy to accomplish what you suggest. For example, dependencies are checked one at a time. So, even if you want to run multiple processes on LIB_DEPENDS, there is no easy way to control CPU load. It is a better idea for other ports UPGRADE utilities to take care of your suggestions. Indeed, I have been developing such utility myself. If you want to try, I can give out for testing. There are 2 known issues with my tool, yet: 1. no good way to run 'make config', yet, and 2. even if less LIB_DEPENDS are required due to less selected OPTIONS, my tool does not fully eliminate these dependencies. Hiro ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshihiro Ota wrote: On Thu, 13 Dec 2007 21:58:57 +0100 Erik Trulsson [EMAIL PROTECTED] wrote: One shortcoming is the lack of locking making parallell builds a bit unsafe. If you try to build both port A and port B at the same time, and both A and B depends (directly or indirectly) on port C which is not installed, then you can esily end up having two processes both trying to build C at the same time. This usually confuses both builds very badly making them fail. I also don't think there is any locking on /var/db/pkg making possibly somewhat unsafe trying to register the installation of two ports/packages at the same time. I have never noticed any actual problems with this though. Some sort of locking, making parallel builds safe, should be possible to add to the ports system without doing any sweeping changes. (I did look briefly at the makefiles, but did not find any obvious place to put the locking. I probably just did not look hard enough.) The ports system is to install a new port. It won't be easy to accomplish what you suggest. For example, dependencies are checked one at a time. So, even if you want to run multiple processes on LIB_DEPENDS, there is no easy way to control CPU load. It is a better idea for other ports UPGRADE utilities to take care of your suggestions. Indeed, I have been developing such utility myself. If you want to try, I can give out for testing. There are 2 known issues with my tool, yet: 1. no good way to run 'make config', yet, and 2. even if less LIB_DEPENDS are required due to less selected OPTIONS, my tool does not fully eliminate these dependencies. Your correct that there are 2 seperate issues at play here but there is a common solution (and to be honest I have yet to see any feature/issue discussed in any of the re-engineering threads that doesn't at least become more manageable under this general design concept I am working under) I hate to keep referring to Miller97 but I think it highlights (directly or indirectly) every single issue that has been discussed while a little off topic (and slightly self serving) there is a good explanation of the general idea behind what I have in mind in the cook tutorial (I am the author thus it is self-serving) http://miller.emu.id.au/pmiller/software/cook/cook-2.30.tut.pdf.. In the the specific case of parallel builds once we pre-scan the DAG it is trivial to do a *FULL* DFS on it and just say for any time two ports are not in the same DFS generated subtree in respect to some root target (can be recursive) they can be build in parallel. Locking is also trivial now that the decision on ordering is made by the ports system and not indivual ports makefiles. (the indivual make files are still needed to build the port but should not and by definition can not contain knowledge about their depends). Side note the more we discuss this the more obvious it becomes to me it has to be in some OO lang and since C++ is the only one in the base system it kind of forces C++ to be the implementation lang. - -- Aryeh M. Friedman FloSoft Systems http://www.flosoft-systems.com Developer, not business, friendly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHY1hWzIOMjAek4JIRArNwAJwMEsZVVMTnl3F4T96BfWGY/PHy2ACaA/RZ NGtCCzJp3z90MwP/UWGrp5o= =tTt4 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Limitations of Ports System
This thread was called results of ports re-engineering survey but I figured I would start a new thread. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. I would be interested in reading about some of the limitations people have run into when using ports. -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Thu, 13 Dec 2007, Steven Kreuzer wrote: This thread was called results of ports re-engineering survey but I figured I would start a new thread. Rightly so. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. I would be interested in reading about some of the limitations people have run into when using ports. Notable with the new modular Xorg is the speed of changes (install/deinstall/clean) when there are a lot of ports installed. Before modular xorg, 400 ports installed was a lot. 700 now is not surprising. Some profiling looking for areas which could benefit from speed optimization would be useful. That may have already been done but not publicized. -Warren Block * Rapid City, South Dakota USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steven Kreuzer wrote: This thread was called results of ports re-engineering survey but I figured I would start a new thread. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. Many of them are not documented... I use it at home and have run into a number of issues (I don't want to restart the flame war that was the previous thread please do a search of the lists for them)... they will be better documented ASAP since enumerating them is part of the re-engineering process I will be conducting (perhaps the last public one) survey specifically focused on features people want and ones that must not be eliminated. Most of them boil down to the ports system was not designed to handle the load it has and incorrectly assumed the following: 1. All maintainers while be extremely careful in how the specify dependency requirements 2. That even though there would be metaports there would none of the current mega metaports 3. Too much trust is placed by the system on the correctness of individual ports -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYYYszIOMjAek4JIRAiA3AJ4s7rHqFRVOMifUj0heeZ/ZzsylJgCdGO93 M0411X/H/NKNto2vi3jY4R4= =+FTw -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Dec 13, 2007, at 10:17 AM, Warren Block wrote: On Thu, 13 Dec 2007, Steven Kreuzer wrote: This thread was called results of ports re-engineering survey but I figured I would start a new thread. Rightly so. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. I would be interested in reading about some of the limitations people have run into when using ports. Notable with the new modular Xorg is the speed of changes (install/ deinstall/clean) when there are a lot of ports installed. Before modular xorg, 400 ports installed was a lot. 700 now is not surprising. Some profiling looking for areas which could benefit from speed optimization would be useful. That may have already been done but not publicized. -Warren Block * Rapid City, South Dakota USA My hunch is that part of the problem lies in the fact (unfortunately) that everything's done via Makefiles and that there's a lot of redundancy to some extent with the operations performed by pkg_install and friends (at least from reading and writing the /var/ db/pkg* and /usr/ports/INDEX* files are concerned), in particular when dealing with non-slave / -master instances, and how make is invoking pkg_install(1). I don't have hard evidence to support that point though, and until that point is reached my comment is merely speculation. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Cooper wrote: On Dec 13, 2007, at 10:17 AM, Warren Block wrote: On Thu, 13 Dec 2007, Steven Kreuzer wrote: This thread was called results of ports re-engineering survey but I figured I would start a new thread. Rightly so. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. I would be interested in reading about some of the limitations people have run into when using ports. Notable with the new modular Xorg is the speed of changes (install/deinstall/clean) when there are a lot of ports installed. Before modular xorg, 400 ports installed was a lot. 700 now is not surprising. Some profiling looking for areas which could benefit from speed optimization would be useful. That may have already been done but not publicized. -Warren Block * Rapid City, South Dakota USA My hunch is that part of the problem lies in the fact (unfortunately) that everything's done via Makefiles and that there's a lot of redundancy to some extent with the operations performed by pkg_install and friends (at least from reading and writing the /var/db/pkg* and /usr/ports/INDEX* files are concerned), in particular when dealing with non-slave / -master instances, and how make is invoking pkg_install(1). I don't have hard evidence to support that point though, and until that point is reached my comment is merely speculation. That is why I plan to use xorg as the test case for the new system namely if it builds xorg in the most efficent way possible then it will be considered good enough for release -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYY92zIOMjAek4JIRAjBoAJ4hi8xhHmreBMKHu7FMnDI+HkYDMACfQfxS wVcLDfmxx33RniSkKLsysYo= =ZLLP -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Thu, Dec 13, 2007 at 11:17:34AM -0700, Warren Block wrote: On Thu, 13 Dec 2007, Steven Kreuzer wrote: This thread was called results of ports re-engineering survey but I figured I would start a new thread. Rightly so. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. I would be interested in reading about some of the limitations people have run into when using ports. Notable with the new modular Xorg is the speed of changes (install/deinstall/clean) when there are a lot of ports installed. Before modular xorg, 400 ports installed was a lot. 700 now is not surprising. Some profiling looking for areas which could benefit from speed optimization would be useful. That may have already been done but not publicized. There were some modifications added to the ports tree earlier this year (I think it was) that resulted in some quite significant speedups when installing/deinstalling ports. There were quite a bit of discussions about it at the time at this list (or possibly one of the other freebsd- lists.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Thu, Dec 13, 2007 at 10:42:43AM -0500, Steven Kreuzer wrote: This thread was called results of ports re-engineering survey but I figured I would start a new thread. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. I would be interested in reading about some of the limitations people have run into when using ports. One shortcoming is the lack of locking making parallell builds a bit unsafe. If you try to build both port A and port B at the same time, and both A and B depends (directly or indirectly) on port C which is not installed, then you can esily end up having two processes both trying to build C at the same time. This usually confuses both builds very badly making them fail. I also don't think there is any locking on /var/db/pkg making possibly somewhat unsafe trying to register the installation of two ports/packages at the same time. I have never noticed any actual problems with this though. Some sort of locking, making parallel builds safe, should be possible to add to the ports system without doing any sweeping changes. (I did look briefly at the makefiles, but did not find any obvious place to put the locking. I probably just did not look hard enough.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
Steven Kreuzer wrote: This thread was called results of ports re-engineering survey but I figured I would start a new thread. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. I would be interested in reading about some of the limitations people have run into when using ports. My personal frustration is the great length of time it takes to do make index and pkg_version (which calls make -V PKGNAME). The problem is that make has to read the entire makefile, including all the includes, before it can decide the value of any variable. I spent quite a while looking for speed improvements in this particular area, and couldn't find anything. I think that you have to dispense with make as the tool that coordinates the building of the ports, and rethink it from scratch. (I more or less came to the conclusion that it would be better to wait ten years until computers are ten times faster, and that in the mean time I could live with this particular problem.) Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Thu, Dec 13, 2007 at 03:00:54PM -0500, Aryeh M. Friedman wrote: That is why I plan to use xorg as the test case for the new system namely if it builds xorg in the most efficent way possible then it will be considered good enough for release You need to pick a much more complicated set of dependencies than Xorg. You should analyse the dependency tree across all ports and then take into account what happens when source changes occur unsynchronised. Take things like those that depend on the various Qt ports. You will see that some depend on Qt3 and others on Qt4. Then consider things that depend on the documentation ports. Please do not fall into the trap of simplifying the requirements and then finding a simpler solution. -- John Birrell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
I just wonder if you asked the general population, whether they'd rather have ports or packages, I bet most would vote for packages, aside from those that actually like watching the compilation output fly by. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Birrell wrote: On Thu, Dec 13, 2007 at 03:00:54PM -0500, Aryeh M. Friedman wrote: That is why I plan to use xorg as the test case for the new system namely if it builds xorg in the most efficent way possible then it will be considered good enough for release You need to pick a much more complicated set of dependencies than Xorg. You should analyse the dependency tree across all ports and then take into account what happens when source changes occur unsynchronised. Take things like those that depend on the various Qt ports. You will see that some depend on Qt3 and others on Qt4. Then consider things that depend on the documentation ports. Please do not fall into the trap of simplifying the requirements and then finding a simpler solution. I was not planning to skimp on the requirements at all but the test case is xorg... i.e. I will do my best to not compermise on features/requirements but xorg meets several criteria for being a good test (out of order building, alt. depends, large but seperatable DAG) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYbPXzIOMjAek4JIRAtmcAJ4rifRtYkufmyFU9LCxqMhx73kZ6ACfe7Nt Ojc2my7xjUH6xoyn+ysHM1U= =mB1y -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On Thu, Dec 13, 2007 at 05:36:07PM -0500, Aryeh M. Friedman wrote: I was not planning to skimp on the requirements at all but the test case is xorg... i.e. I will do my best to not compermise on features/requirements but xorg meets several criteria for being a good test (out of order building, alt. depends, large but seperatable DAG) But it all comes from one source and is released as one set. You need to think about things that are released from different places with different dependencies at different times. And then allow for the lag of getting the FreeBSD part updated. -- John Birrell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Birrell wrote: On Thu, Dec 13, 2007 at 05:36:07PM -0500, Aryeh M. Friedman wrote: I was not planning to skimp on the requirements at all but the test case is xorg... i.e. I will do my best to not compermise on features/requirements but xorg meets several criteria for being a good test (out of order building, alt. depends, large but seperatable DAG) But it all comes from one source and is released as one set. You need to think about things that are released from different places with different dependencies at different times. And then allow for the lag of getting the FreeBSD part updated. Perl, python and other pre-reqs to xorg are not from the same source thus fit the requirement I should of been more specific by saying xorg+all pre-req ports. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYbZszIOMjAek4JIRAueZAJ9zDRfMpYYNrXrik1VYFLvEXW86/QCfVqNo smhJVbQZqx269CJnoK2NMAQ= =Hf6H -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Danny Pansters wrote: On Thursday 13 December 2007 19:17:34 Warren Block wrote: On Thu, 13 Dec 2007, Steven Kreuzer wrote: This thread was called results of ports re-engineering survey but I figured I would start a new thread. Rightly so. On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: We *know* it can be done better. We *know* the scaling limits of the current system, and most of us are completely amazed it even still works. If y'all want to make a difference, concepts and ideas we have plenty of. Code talks. Out of curiosity, are any of these shortcomings documented anywhere? I have been using ports on my home machine for a long time and I've never had any problems with it. I assume the issues come into play when you work with multiple systems you are trying to keep in sync, etc. I would be interested in reading about some of the limitations people have run into when using ports. Notable with the new modular Xorg is the speed of changes (install/deinstall/clean) when there are a lot of ports installed. Before modular xorg, 400 ports installed was a lot. 700 now is not surprising. Some profiling looking for areas which could benefit from speed optimization would be useful. That may have already been done but not publicized. Well, I can tell you what I think: If we don't want thousands of global knobs, then it's either splitting up in almost atomic micro ports which inflates the number of ports or using port OPTIONS... BUT... we currently have no standard mechanism to actually use another port's OPTIONS in a somewhat generic way. It's all about where and how you want to have your granularity (sp?) I think. An other option is keep the knobs in a centeral DB but only ask for ones the port being currently being compiled requires and all other values are cached. Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. In the longer run, being able to specify a port's options when specifying DEPENDS would probably be a very useful and not very invasive change for the better (or maybe if that's simpler -- doubt it -- some sort of OPT_DEPENDS). If someone wants to work specifically on addressing - to put it bluntly - the debianizing-ports-versus-optionifying-properly issue I'm interested in chipping in or if needed leading such an effort. The scope should be only that and it must be backwards compatible. There is enough dependancy (and alt versioning) issues they must be addressed also. The alt versioning alone will require a complete redesign I think thus we mightest well throw in port/package interchangability. So I am leaning towards a ground up rewrite unless some can show how to get real dependancy management and alt. versions into the existing framework. Note neither should complicate the current system any more then absulutely needed and any such compilcation should be on the maintainers and portmgr only (hopefully none). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYfnizIOMjAek4JIRAisNAKCQ2VZ2wibSFinuKAztxJlvI6dbPQCdEgbQ SnHPQr+mrf9aImgj8iL7ZMI= =RuoC -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
