Re: Has the port collection become to large to handle.
fbsd wrote: Modify the master make code to post a count to a special purpose FreeBSD website by passing it a cookie. Now every time a any user runs the port make install that special purpose FreeBSD website will be accessed counting how many times that port is really executed. Then use that count per new release of FreeBSD to determine the ports that go into the commonly used category. I always thought of such a scheme too. Like the afterboot-manpage (IIRC) on OpenBSD, where people are encouraged to mail their dmesg output to the developers. The comments from one of the maintainers about the fact that the maintainers are not allowed to build the official packages is a policy that can easily be changed. Hell no. Putting the burden on maintainers to build packages for various architectures and releases is completely utopical. Not to mention the fact, that they would have to build them in sandboxes much like the package build cluster. configure script often pick up random libraries to link against, if these are not recorded as @pkgdep then the package is mostly useless for other people. Its more important to have timely packages available then the security of waiting for the mass package build done once per new FreeBSD version release. Packages are built on a regular basis, I suggest you get more familiar with the package building and RE process before starting heated discussions on ports@ This also allows the maintainer to build different versions of the package for each different version of major dependents such as php4/5 apache1/2 mysql3/4/5 whatever. The mass package build process does not allow this flexibility. I already wrote my thoughts about a FLAVOUR system, where multiple packages are built per port. Sadly, people seem to think that slave ports are the way to go. But not only do they eat up precious inodes, increase the fake count of ports/packages available, and increase INDEX build times. They are also only deemed worthy for important ports, whatever that means. If you would commit a slave port for every port that can be built with mysql XOR postgresql, you get an unmaintainable mess. Not to mention that you violate the one fact in one place rule. Having duplicate ports, that are almost the same scattered throughout the ports system is obviously not helpful. The resources and time needed for performing the secure massive package built must impact the release timeline of new FreeBSD releases. Doing away with it may streamline many other different internal release process. There is a dedicated package build cluster, it does in no way interfere the RE process. Please read up on the mentioned topics, thanks. Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgp00wOvajCdU.pgp Description: PGP signature
Re: Has the port collection become to large to handle.
On Mon, 15 May 2006 23:47:50 -0400 Robert Huff [EMAIL PROTECTED] wrote: Chris Hill writes: IMHO, your gripes are misdirected - complain to your ISP about the speed and reliability of your service. This should NOT take two hours. It could also be a matter of using the wrong server for your time and place. A data point: I just pulled a fresh copy of the tree into virgin space. Time (as reported by cvsup) : 46m42s Size (as reported by du) : 301.2 mbytes The mirror is 6 hops out, and located at M.I.T.. (Almost next door.) My connection is 7 megabit cable. Pulling down an entire tree into a virgin directory is not efficient use of cvsup. Not even a little. While it _can_ be done (as you've demonstrated) if you're looking for performance, pull down a tarball, unpack it, then run cvsup to update it, and I bet it will be considerably faster. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Has the port collection become to large to handle
To fbsd: Man,stop the trolling shit for good. You have /usr/ports/misc/porteasy,use it and leave us alone. You are just too much. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
At 20:28 13.05.2006, fbsd wrote: To all question list readers; Now with 14576 ports in the collection where do you draw the line that its too large to be downloading the whole collection when you just use 10 or 20 of them? The port collection is growing at a ever increasing rate per month. The mass majority of the ports are so special purpose that only a very few people have need of them. Sure there are ways to limit the categories you select to download, but still the size of the most used categories is too large and loaded with ports not commonly used by the general user. So people them use the packages. But the problem with the packages is they are not updated every time changes are made to the port they were created from. Also packages that have dependants like php4/php5 or mysql4/mysql5 are not being updated to use the newer versions of those dependants as they come out. I for one think the port/package collection has already grown to large to handle in it's present state. Users are consuming massive bandwidth to download and it consumes a very large chunk of disk space. Saying nothing about the wasted resources consumed to back it up repeatedly. I have gone to using the package version for everything and only downloading the ports config files for packages that I need to compile from scratch to change some add on function. This methodology has worked fine since FreeBSD version 3.0 as I used each new release of FreeBSD up to 6.1. Now in 6.1 there is problems with packages that have not been recreated using the new system make file. This problem is caused by there being no mandatory requirement on the ports maintainers to recreate the packages any time one of the dependants change or when changes are made to the canned make process or when dependants show up as broken. Yes I know what a large task this is and that it requires a lot of run time to accomplish. So my question is how do we users make our needs known to the ports maintainer group so that will seriously address the problem of the packages being outdated? Are there other people on this list who are dissatisfied with the packages and the problems associated with using packages and ports mixed together? What are your thoughts about requesting the ports group to create a new category containing just the ports most commonly used including their dependents and making this general category the default used to download. This would be a much smaller sized download containing everything necessary to build the most used ports. Many of the dependents are used over and over by many different port applications. This new category would them be given priority in keeping their packages up to date. Could even take this idea one step further and say that only ports in this category will have packages built and keep up to date. All ports not in this special category will not have packages built at all. I think this would help the port group to better manager their people resources and serve the needs of the user community better. Another idea I would like to throw out to the list is how about requesting the ports group to add a function to packages so the installer of the package can select what version of the dependent components should be included in the install. Much like make config does in the ports system? The packages system already automatically launches the download of dependent packages so why not give the installer the option to select which version of the dependent to fetch. Like in php4/5 or mysql4/5 or apache 13/20. This way the package is more flexible and the port maintainer does not have to build a different version of the parent package for each version of the dependant which is available. The whole idea behind this post is to give the general users who reads this questions list an opportunity to brainstorm about ways to make the ports/package collection better and easier to use. This may help the ports group in understanding the needs and direction we the users would like to see the management of the collection to take. If we don't speak up they will just think things are ok as they are now. FreeBSD is a public project. The ports group are not the only users who can give input about the direction and policies concerning the future of the ports/package collection. All feedback welcome. Hello! I would just like to direct you to one of my previous threads: http://lists.freebsd.org/pipermail/freebsd-questions/2006-March/115402.html It was not warmly welcomed though. All the best, Kyrre ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Chris wrote: On 15/05/06, fbsd [EMAIL PROTECTED] wrote: Keep the ports tree how it is, as others have said the size is small on modern hard drives and bandwidth trivial, once the initial ports tree is in place keeping it up to date needs very little bandwidth and its only distfiles that tend to be large, but you only download distfiles for ports you install so this is a very good system. If at least one person uses a port it is justified and I very much like that most tiny apps I search for in the ports tree do indeed exist. How would you define commonly used ports? we would end up with a favouritism system in place and many arguments about which ports would be included in the commonly used group, you also forget that many ports that may look meaningless from where you sit are necessary as dependants to other ports. There would be not arguments as stats dont lie. Please read the entire thread there are some good ideas in there which would speed up day to day use of ports for everyone. Where you get the idea that ports is quick to maintain is beyond me it takes a good 30mins to sync up if your a few months out of date now a days. 30mins is not much if you have 1 machine but add it all up for a large number of machines and its a significant amount of time which we all could better spend doing other things instead of waiting for a cvsup to complete. Is php4 out of date? no its still been maintained and is more suitable for many people, likewise with mysql 4.1. Openssl 0.9.7 all are older branches but not out of date. The ports system is very clever in how it is so adaptive eg. Ruby needs openssl and if you have 0.9.7 it sets that as the dependency rather then 0.9.8. No hacking of makefiles needed. No ones saying they are, we use mysql 4.0 here but as what's being suggested would: 1. use real world usage stats 2. provide a much faster way of obtaining just the ports you want Then there are now down falls that I can see, only the benefit of being able to update from ports much much quicker than is currently possible. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Spadge wrote: fbsd wrote: fbsd wrote: * so working with in that same procedure the maintainer passes the packages to the audit people and they pass it on. No problem with this at all. Thus removing any kind of streamlining to speed up releases of new versions? the port make method will still be there for all ports with limited usage history, it will just not have a package for it because it has limited usage. And this is the crux of the matter. Would phpmyadmin have a php5/mysql4 version? Or do the majority of users use php4 still? And are there more test boxes than there are production servers? Is it fair to say the most commonly used ports are not the most commonly used packages? I would imagine that something like KDE would be a hugely popular package, on account of the sheer size of the beast, but that it wouldn't be the most popular port due to the number of people who don't run a GUI on their system. There is also the fact that you could fairly easily abuse this system if you wanted your software to be included in the 'most commonly used' list, by just hammering the server. There is no privacy issues. Passing cookies is normal and done as matter of fact by most commercial websites and any website that uses php session control makes cookies by default. This is a no-issue issue. Every browser on the planet has the option to disable cookies (in the same way that email clients have the option of indenting quoted text - it's a standard required feature). This is because it is a privacy issue. Different people have different views on what privacy is or isn't, and that's nine tenths of the entire point: we don't get to decide what their privacy levels are, they do. I can totally understand why you think this system would be better for you. I just hope you can understand why it wouldn't be better for everyone, nor even for the majority of people. Now, Marc G. Fournier's dynamic personalised ports tree suggestion ... that's a *real* idea. Agreed in full. Cookies and similar are, in my opinion, invasive, and this is why I have my browser set to ask me each time, and get rid of anf I accept when I close the browser. But other people love the benefits of cookies. Choice is the only real power. And, Marc G. Fournier definitely had something with his description of how the port system should work, when I read his post I was thinking that is exactly how I would have designed it as well (admittedly, when it was designed, it wasn't the size it is now). Regards, Adrian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Mark Linimon wrote: On Sun, May 14, 2006 at 02:04:55PM +0300, Panagiotis Astithas wrote: I believe that one solution to the scalability problem of creating and maintaining updated packages, would be to decentralize it more. Each time I submit an update for one of the ports I maintain, I've already build the relevant packages, as a QA measure. There should be no need to wait for the ports cluster to build the official version, instead of using my own, modulo perhaps the higher quality assurance you'd get from Kris's build infrastructure. You have built the package for one build environment (buildenv). There are 12. See http://portsmon.freebsd.org/portsoverall.py. Quite right. But I think that would still be helpful to the majority of users (of packages). If a maintainer can't build a package for a particular build environment due to lack of resources, we can always use the regular cluster builds for these architectures. We just gained a more timely release of the most wanted package(s), no? Frankly, the availability of up-to-date packages is the only issue from this thread I really care about. I've been contemplating about graphical package installers for FreeBSD for some time and most ideas fall short since there would not be much point in using a package installer without... er... packages :-) Regards, Panagiotis ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Steven Hartland wrote: Chris wrote: On 15/05/06, fbsd [EMAIL PROTECTED] wrote: Keep the ports tree how it is, as others have said the size is small on modern hard drives and bandwidth trivial, once the initial ports tree is in place keeping it up to date needs very little bandwidth and its only distfiles that tend to be large, but you only download distfiles for ports you install so this is a very good system. If at least one person uses a port it is justified and I very much like that most tiny apps I search for in the ports tree do indeed exist. How would you define commonly used ports? we would end up with a favouritism system in place and many arguments about which ports would be included in the commonly used group, you also forget that many ports that may look meaningless from where you sit are necessary as dependants to other ports. There would be not arguments as stats dont lie. Please read the entire thread there are some good ideas in there which would speed up day to day use of ports for everyone. Where you get the idea that ports is quick to maintain is beyond me it takes a good 30mins to sync up if your a few months out of date now a days. 30mins is not much if you have 1 machine but add it all up for a large number of machines and its a significant amount of time which we all could better spend doing other things instead of waiting for a cvsup to complete. This is why there are options in place that would allow you to download the cvsup to one of you computers, likely a server of some sort, and your other computers all retrieve the CVSup from this local server, significantly speeding up the retrieval time and decreasing the load on the primary servers, a win for everyone. If you have computers of varying architectures or in seperated geographical locations this would not work as worded, but from your wording it sounded like you had a local LAN of computers. Ohh, and for your informations, statistics do lie, that is the point of statistical analysis, which I spent 1 1/2 years of my life studying before changing into my current Software Engineering/Computer Security degree. And, the arguements would arise from the common ports/packages directory, a suggestion of fbsd's I believe, whereby common ports that would not be built often primarily due to their size, and so wouldn't show up in statistics (such as Gnome, KDE, OpenOffice, and a number of others), would be placed into a common directory of the ports/packages tree, and would be exempt from these statistics. The arguements would arise over what should be placed into this common directory. And what about the case of a port that would be built many times over its lifetime, mainly due to program version changes? The first one that springs to mind would be Firefox. Firefox has had a number of version changes in the same space of time that Exim, a very commonly used mail server application, has been updated, and assuming an even distribution of mail servers and desktop users with firefox, firefox would appear to be 10-20 times more active over it's lifetime. It is also common for people with a desktop computer to format their HDD every 3 months or so, and every time this occured, the desktop PC ports (Xorg, Firefox, KDE/XFCE/GNOME, OpenOffice.org, etc.) would get a rebuild/redownload, again throwing the stastics out of whack. Just my $0.02. Regards, Adrian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Has the port collection become to large to handle.
Keep the ports tree how it is, as others have said the size is small on modern hard drives and bandwidth trivial, once the initial ports tree is in place keeping it up to date needs very little bandwidth and its only distfiles that tend to be large, but you only download distfiles for ports you install so this is a very good system. If at least one person uses a port it is justified and I very much like that most tiny apps I search for in the ports tree do indeed exist. How would you define commonly used ports? we would end up with a favouritism system in place and many arguments about which ports would be included in the commonly used group, you also forget that many ports that may look meaningless from where you sit are necessary as dependants to other ports. Is php4 out of date? no its still been maintained and is more suitable for many people, likewise with mysql 4.1. Openssl 0.9.7 all are older branches but not out of date. The ports system is very clever in how it is so adaptive eg. Ruby needs openssl and if you have 0.9.7 it sets that as the dependency rather then 0.9.8. No hacking of makefiles needed. Chris ** The point being made by the OP is the packages are not being kept up to date and the usage of packages ports don't work together because of the overall size of the collection. How does what you posted address the packages? *** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Adrian Pavone wrote: Steven Hartland wrote: This is why there are options in place that would allow you to download the cvsup to one of you computers, likely a server of some sort, and your other computers all retrieve the CVSup from this local server, significantly speeding up the retrieval time and decreasing the load on the primary servers, a win for everyone. If you have computers of varying architectures or in seperated geographical locations this would not work as worded, but from your wording it sounded like you had a local LAN of computers. You couldnt be more wrong there even though the cvsup source might as well be on the local LAN we have such a quick connection to it. The shear volume of files that have to be checked adds a significant amount of time to any method to syncing them, from cvsup local rsync to tar I've tried them all. Ohh, and for your informations, statistics do lie, that is the point of statistical analysis, which I spent 1 1/2 years of my life studying before changing into my current Software Engineering/Computer Security degree. Your just being pedantic, you know quite well what was ment. And, the arguements would arise from the common ports/packages directory, a suggestion of fbsd's I believe, whereby common ports that would not be built often primarily due to their size, and so wouldn't show up in statistics (such as Gnome, KDE, OpenOffice, and a number of others), would be placed into a common directory of the ports/packages tree, and would be exempt from these statistics. The arguements would arise over what should be placed into this common directory. The suggestion was capable of registering either when installed by ports or packages so a mute point. And what about the case of a port that would be built many times over its lifetime, mainly due to program version changes? The first one that springs to mind would be Firefox. Firefox has had a number of version changes in the same space of time that Exim, a very commonly used mail server application, has been updated, and assuming an even distribution of mail servers and desktop users with firefox, firefox would appear to be 10-20 times more active over it's lifetime. And your point being? It is also common for people with a desktop computer to format their HDD every 3 months or so, and every time this occured, the desktop PC ports (Xorg, Firefox, KDE/XFCE/GNOME, OpenOffice.org, etc.) would get a rebuild/redownload, again throwing the stastics out of whack. No its still being used isnt it which is what we are interested in. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
And what about the case of a port that would be built many times over its lifetime, mainly due to program version changes? The first one that springs to mind would be Firefox. Firefox has had a number of version changes in the same space of time that Exim, a very commonly used mail server application, has been updated, and assuming an even distribution of mail servers and desktop users with firefox, firefox would appear to be 10-20 times more active over it's lifetime. And your point being? It is also common for people with a desktop computer to format their HDD every 3 months or so, and every time this occured, the desktop PC ports (Xorg, Firefox, KDE/XFCE/GNOME, OpenOffice.org, etc.) would get a rebuild/redownload, again throwing the stastics out of whack. No its still being used isnt it which is what we are interested in. I'm sorry, but when I read the continual posts on this topic, all stated that the count would occur while installing, not in usage. If the suggestion was that the FreeBSD system would report what packages where being used on a regular basis (the only way to properly record what ports/packages were being used), then that is an entirely seperate discussion, and one that I have not addressed to this point. However, If that was your suggestion, then I am extremely glad that is not how the ports system currently operates, for the same reason I am glad that spyware is not installed on my computer. If you do not have a regular reporting to home base mechanism in place, then how would you be able to monitor what is still being used .. which is what we are interested in? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
maybe this is a bit off target, but it seems to me the ports tree is not too large: I've found stuff I've wanted that wasn't on the ports tree. I think it's too small. Unless you are on a 56k, but then everything ports related will be painful. However a reoganization could be in order... Currently we have: portbase/category/port/ Each category could have hundreds of ports that are related in the category, but clutter a search, especially in categories with over 100 ports... My suggestion, why not add another level: portbase/category/subcategory/port/ As well as some virtual categories, such as all perl, python, php, and c_c++ will be put under lang as sub-categories, with _all_ modules for these languages, and then if you are thinking mysql access for python while doing your ports search, you'll go to the databases/mysql/ subcategory, and see a symlink to the python module to access mysql. And then there would be a dependancy translation table: it if a dependancy isn't found, it'll look on the table, which will convert from the current structure to the new structure within the port make system, and hopefully prevent most/all change issues. Sorry if this suggestion is too farr off the topic (or already been posted, I got about half way through, and found I need to get to work...) Thanks, -Jim ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Just remember it has to be a /better/ mousetrap. wouldn't it be a peopletrap in this case, since it's for people? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
I do use the ports mechanism on my FreeBSD systems exclusively due the possibility of making the system components meshing and working in unison instead of version and dll-hell. And now and then I find some obscure port that fits the current needs - And again the ports system makes the whole process painless. As such I see and feel very little need making the ports system smaller or more lightweight as there are other way to make downloading and using the ports in larger setups minor bindwidth or resource eater. However a reoganization could be in order... Currently we have: portbase/category/port/ Some kind of reorganization could be in order, if a good way doing it could be found. At one point I tended to drop the language and some other catergories from cvsup fetch, but it made building the INDEX next to impossible causing me reverting to full ports fetch again. I dont know if indexing in separate categories or some such solution would be feasible, but of course fetchindex target makes the indexing of partial port trees feasible. Then of course there has to be good reasons for creating separate trees for non-english ports, but one thing I've thought is that if those could be put into main port build directory and enabled with a build knob or maybe making them some kind of metaports without needing their own directory hierarchy. All in all the ports sytem, even as it is nowadays, in its present size is one of the reasons which make FreeBSD for me a unixish OS of choice. An all packaging solution would be a major pain to maintain. I'm running Apache, PHP, Postgres etc. in my web server setups these days and there is no way I'd go to MySQL. There are just too many combinations of different components used in similar setups to make packages only solution feasible *without* limiting the choice the present system gives us in building the machines to suit our needs. -Reko ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Has the port collection become to large to handle.
The best indicator that the ports collection has become to large is that it took me 2 hours to download the complete port-all collection using A DSL internet connection. To compile the ports I use took another 11 hours. This is the reason I went to using packages in the first place. Downloading the complete port collection when I had a dial up connection would go maybe 35 min and them get suspended by the cvs site. I would rerun the job over and over again sometimes taking a week or better to finally get it completed. This makes the download of the complete port collect almost impossible for dial up users. On 6.0 I installed all the ports I use by the package method in less than 10 min. In 6.1 release changes were made that no longer allow packages to work with ports as dependents. Packages have to have the ability to give the installer the ability to select the dependents versions for such primary applications as php3/4/5 mysql3/4/5. Also the ports and packages have to return to being able to work together like in FreeBSD versions older than 6.1. Or more versions of certain ports that interface with other primary application have to be carried in the collection. The design of the working collection needs to be made more user friendly for everybody including the dial up users. Some very good ideas have been put forth and should get serious attention by the FreeBSD foundation management. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
fbsd wrote: The best indicator that the ports collection has become to large is that it took me 2 hours to download the complete port-all collection using A DSL internet connection. To compile the ports I use took another 11 hours. This is the reason I went to using packages in the first place. And installing it from the same CD that you installed the OS from would take about 1 minute. If you choose a method to install the ports that take several hours, should the FreeBSD folks take the blame for your choice? A 33.bKbps dialup connection should download the entire ports collection in under 3 hours. And DSL connection should do it in significantly less time. Even a 270Kbps down DSL connection should be able to snatch the whole thing in just over 20 minutes. If I had a dialup connection or the uncredibly slow DSL connection you mention, I don't think I'd make the same choice that you made. I'd install from the CD. Updating through cvs might take 45 minutes then. Downloading the complete port collection when I had a dial up connection would go maybe 35 min and them get suspended by the cvs site. I would rerun the job over and over again sometimes taking a week or better to finally get it completed. This makes the download of the complete port collect almost impossible for dial up users. And yet, not once did you ever try to install from the CD? Why would you beat your head against the wall like that? -- Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ smime.p7s Description: S/MIME Cryptographic Signature
RE: Has the port collection become to large to handle.
On Mon, 15 May 2006, fbsd wrote: The best indicator that the ports collection has become to large is that it took me 2 hours to download the complete port-all collection using A DSL internet connection. Ah, the crux of the matter. I'd guess that was the driving force behind this entire thread. IMHO, your gripes are misdirected - complain to your ISP about the speed and reliability of your service. This should NOT take two hours. It could also be a matter of using the wrong server for your time and place. If you haven't already, look into the port (or package) sysutils/fastest_cvsup. To compile the ports I use took another 11 hours. To me this would be an objectionably long time too, but it's completely irrelevant to the issue at hand. The time it takes to compile the ports one uses is mainly a function of how much there is to compile. I've also found that things go a little faster on the 3.4GHz P4 than they do on the 266MHz K6-2 :^P This is the reason I went to using packages in the first place. Fair enough. Downloading the complete port collection when I had a dial up connection would go maybe 35 min and them get suspended by the cvs site. I would rerun the job over and over again sometimes taking a week or better to finally get it completed. This makes the download of the complete port collect almost impossible for dial up users. When I was doing this stuff by dialup I never had such problems. Yes, it took forever, but I expect that when using dialup. I would start the process and go to bed; in the morning it would be done. Seriously, maybe you had a bad phone line. My house is 50 years old, and I've found a crusty wire or two. On 6.0 I installed all the ports I use by the package method in less than 10 min. In 6.1 release changes were made that no longer allow packages to work with ports as dependents. The other crux of the matter. Since this (plus the download time, which is a network issue) seems to be the meat of your complaint, why not post on that subject, instead of asking for drastic changes to the ports/packages system? Realistically, which of these requests seems more likely to be addressed by the perpetually-swamped developers? [snip] The design of the working collection needs to be made more user friendly for everybody including the dial up users. It's really pretty user-friendly as it is, for those who understand how to use cvsup and the various port upgrading tools (and I think that includes you). -- Chris Hill [EMAIL PROTECTED] ** [ Busy Expunging | ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Date: Sat, 13 May 2006 14:28:49 -0400 From: fbsd [EMAIL PROTECTED] Subject: Has the port collection become to large to handle. To: [EMAIL PROTECTED] ORG freebsd-questions@FreeBSD.ORG Cc: [EMAIL PROTECTED] I for one think the port/package collection has already grown to large to handle in it's present state. Users are consuming massive bandwidth to download and it consumes a very large chunk of disk space. Saying nothing about the wasted resources consumed to back it up repeatedly. What's your domain name again? cvsup downloads only the bits of the port tree that have changed. An intelligent backup strategy backs up the entire tree infrequently, and the rest of the time, backs up only the files that have changed. And since the ports tree is readily available off the net, why back it up at all? This problem is caused by there being no mandatory requirement There is no mandatory requirement on anyone to do anything. So my question is how do we users make our needs known to the ports maintainer group so that will seriously address the problem of the packages being outdated? I suggest you purchase one or more high-powered build machines and ship them prepaid to the ports maintainer. Repeat every eight or ten months to ensure that the build machines remain state-of-the-art. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Has the port collection become to large to handle.
Chris Hill writes: IMHO, your gripes are misdirected - complain to your ISP about the speed and reliability of your service. This should NOT take two hours. It could also be a matter of using the wrong server for your time and place. A data point: I just pulled a fresh copy of the tree into virgin space. Time (as reported by cvsup) : 46m42s Size (as reported by du) : 301.2 mbytes The mirror is 6 hops out, and located at M.I.T.. (Almost next door.) My connection is 7 megabit cable. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On Sat, 2006-May-13 22:37:01 -0500, Joseph Kerian wrote: The resemblance is not, in and of itself, a bad thing. Is there anything preventing someone from making a portupgrade-like tool that uses only tmp, a /ports dir on an ftp site and a bit of intelligence regarding dependency resolution? Correct me if I'm wrong, but I'm not seeing any technical reasons this couldn't be done. (okay... so your equivelent of portversion might get a little more complicated or potentially wierd) The biggest problem I see is keeping just your local ports subset up-to-date (so when you do a 'make foo', you can be sure that all the dependencies - including ports/Mk are up to date). CVSup and CTM are not designed to do this (though CVS can mostly manage it) so the portupgrade-like tool would need to manage this itself. I would submit, however, that it hasn't been done simply because it isn't needed. 210 mb is laughably insignificant on any system I would build ports. As a CVS checkout (in a 16k/2k filesystem), my ports tree is nearly 500MB and 190,000 inodes. Without the CVS metadata, it's 327MB and just over 100K inodes. The size is fairly irrelevant (especially in the face of ports that need 2-4GB to build) but the 100K-200K inodes is non-trivial. -- Peter Jeremy ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
fbsd wrote: So people them use the packages. But the problem with the packages is they are not updated every time changes are made to the port they were created from. Also packages that have dependants like php4/php5 or mysql4/mysql5 are not being updated to use the newer versions of those dependants as they come out. I believe that one solution to the scalability problem of creating and maintaining updated packages, would be to decentralize it more. Each time I submit an update for one of the ports I maintain, I've already build the relevant packages, as a QA measure. There should be no need to wait for the ports cluster to build the official version, instead of using my own, modulo perhaps the higher quality assurance you'd get from Kris's build infrastructure. This is what you usually get in the Windows/Mac/Linux world. Macromedia, for instance, provides their own packages for Flash, naturally. The Eclipse foundation provides binary packages for, say Linux, but Red Hat has chosen to provide its own rpm's from their repo. What if we taught pkg_add to use something like INDEX, instead of a global PACKAGESITE variable, to hold information about each port's remote site? What if this was the secondary site, while the freebsd.org one remained the primary? This way you'd try to get the official package first and if you failed to find it, you'd get the maintainer's copy. Many people (myself included) have been doing something similar for GNOME and KDE, by asking portupgrade to try the marcuscom and fruitsalad repositories first. Or how about we don't consume the cluster's capacity for building packages, but just for QA? Why not require me (the maintainer) to send-pr a URL to fetch the package's from and store them in the cluster (or straight to ftp-master)? Of course this would not work for people without the means to host the packages, or for unmaintained ports. We'd still have to use the ports cluster for them. For the security paranoid, add a big fat warning, that the contents of these packages are not verified or endorsed by the project. Maybe even, use two download locations: one for packages built by the cluster and another for packages submitted by the maintainers. IIUC, most Linux distributions have a similar arrangement. Bottom line, since the package building role is becoming unbearable (at least for a timely delivery) for the project, why not let the ones who are already creating packages on their own, share the burden? Regards, Panagiotis P.S.: it hasn't escaped me that using packages created from different systems could present dependency mismatches. But I would argue that this should be the maintainer's concern and moreover, it is something that is deemed acceptable in other systems. Furthermore, one could always use the ports system if he prefers. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
At 20:28 13.05.2006, fbsd wrote: To all question list readers; Now with 14576 ports in the collection where do you draw the line that its too large to be downloading the whole collection when you just use 10 or 20 of them? The port collection is growing at a ever increasing rate per month. The mass majority of the ports are so special purpose that only a very few people have need of them. Sure there are ways to limit the categories you select to download, but still the size of the most used categories is too large and loaded with ports not commonly used by the general user. So people them use the packages. But the problem with the packages is they are not updated every time changes are made to the port they were created from. Also packages that have dependants like php4/php5 or mysql4/mysql5 are not being updated to use the newer versions of those dependants as they come out. I for one think the port/package collection has already grown to large to handle in it's present state. Users are consuming massive bandwidth to download and it consumes a very large chunk of disk space. Saying nothing about the wasted resources consumed to back it up repeatedly. I have gone to using the package version for everything and only downloading the ports config files for packages that I need to compile from scratch to change some add on function. This methodology has worked fine since FreeBSD version 3.0 as I used each new release of FreeBSD up to 6.1. Now in 6.1 there is problems with packages that have not been recreated using the new system make file. This problem is caused by there being no mandatory requirement on the ports maintainers to recreate the packages any time one of the dependants change or when changes are made to the canned make process or when dependants show up as broken. Yes I know what a large task this is and that it requires a lot of run time to accomplish. So my question is how do we users make our needs known to the ports maintainer group so that will seriously address the problem of the packages being outdated? Are there other people on this list who are dissatisfied with the packages and the problems associated with using packages and ports mixed together? What are your thoughts about requesting the ports group to create a new category containing just the ports most commonly used including their dependents and making this general category the default used to download. This would be a much smaller sized download containing everything necessary to build the most used ports. Many of the dependents are used over and over by many different port applications. This new category would them be given priority in keeping their packages up to date. Could even take this idea one step further and say that only ports in this category will have packages built and keep up to date. All ports not in this special category will not have packages built at all. I think this would help the port group to better manager their people resources and serve the needs of the user community better. Another idea I would like to throw out to the list is how about requesting the ports group to add a function to packages so the installer of the package can select what version of the dependent components should be included in the install. Much like make config does in the ports system? The packages system already automatically launches the download of dependent packages so why not give the installer the option to select which version of the dependent to fetch. Like in php4/5 or mysql4/5 or apache 13/20. This way the package is more flexible and the port maintainer does not have to build a different version of the parent package for each version of the dependant which is available. The whole idea behind this post is to give the general users who reads this questions list an opportunity to brainstorm about ways to make the ports/package collection better and easier to use. This may help the ports group in understanding the needs and direction we the users would like to see the management of the collection to take. If we don't speak up they will just think things are ok as they are now. FreeBSD is a public project. The ports group are not the only users who can give input about the direction and policies concerning the future of the ports/package collection. All feedback welcome. Hello! I would just like to direct you to one of my previous threads: http://lists.freebsd.org/pipermail/freebsd-questions/2006-March/115402.html It was not warmly welcomed though. All the best, Kyrre ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Has the port collection become to large to handle.
Comments have been posted about how to determine in a fair way which ports would be included in the most commonly used category? The solution to that concern is pretty easy to do. Modify the master make code to post a count to a special purpose FreeBSD website by passing it a cookie. Now every time a any user runs the port make install that special purpose FreeBSD website will be accessed counting how many times that port is really executed. Then use that count per new release of FreeBSD to determine the ports that go into the commonly used category. The side benefit is this would also bring to light the dead and unused ports that can be removed from the ports collections or put in an unsupported category which would further help in controlling the size of the base collection. Of course some precautions in counting the hits to the special purpose FreeBSD website would have to be used to drop attempts by people trying to manipulate the results in favor of some particular port. The comments from one of the maintainers about the fact that the maintainers are not allowed to build the official packages is a policy that can easily be changed. Its more important to have timely packages available then the security of waiting for the mass package build done once per new FreeBSD version release. A warning comment in the maintainer built package informing the installer that this package was built by the maintainer and not by the secure mass package build process will give the installer the info he needs to decide if they want to use that version of the package or wait for the official secure built version. This also allows the maintainer to build different versions of the package for each different version of major dependents such as php4/5 apache1/2 mysql3/4/5 whatever. The mass package build process does not allow this flexibility. The fact is the maintainer is all ready being trusted to manage the port so I see no reason NOT to trust him to create the matching package. Even the need of the secure massive package built process is now questionable. The resources and time needed for performing the secure massive package built must impact the release timeline of new FreeBSD releases. Doing away with it may streamline many other different internal release process. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On Sat, May 13, 2006 at 08:49:51PM -0400, Frank Laszlo wrote: under a given measure ( to be decided again by stats ) said port is moved to a secondary port group. Eww, sounds like a good definition of spyware, I could go without people knowing exactly what I install and when. I for one wouldn't mind supporting this project. You for one would mind. You can't make everybody happy. And the immediately shouting of the equivalent of the word Nazi doesn't help neither. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Has the port collection become to large to handle.
fbsd wrote: The fact is the maintainer is all ready being trusted to manage the port so I see no reason NOT to trust him to create the matching package. Because they don't. The port maintainer is trusted to maintain the port ... and then a bunch of people are trusted to audit the ports before the update is allowed in to the ports tree. Or at least, that's how I thought it worked. * so working with in that same procedure the maintainer passes the packages to the audit people and they pass it on. No problem with this at all. Even the need of the secure massive package built process is now questionable. The resources and time needed for performing the secure massive package built must impact the release timeline of new FreeBSD releases. Doing away with it may streamline many other different internal release process. The personalised dynamic ports tree is by far the best suggestion so far. A 'most commonly used' ports tree is a daft idea, IMHO, and I fully expect myself to be one of those people who uses quite a few ports that would never make it on to that list. And it's not like I do a lot weird stuff, either. I just think that with the number of fbsd users on this planet, coupled with the number of ports in the tree ... well, there's going to be an awful lot of minorities. the port make method will still be there for all ports with limited usage history, it will just not have a package for it because it has limited usage. Also, I think the idea of having a central database to monitor which ports are used has privacy issues, which will require every port to have a privacy disclaimer and an opt-out option. So much for streamlining. There is no privacy issues. Passing cookies is normal and done as matter of fact by most commercial websites and any website that uses php session control makes cookies by default. This is a no-issue issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Edwin Groothuis wrote: On Sat, May 13, 2006 at 08:49:51PM -0400, Frank Laszlo wrote: under a given measure ( to be decided again by stats ) said port is moved to a secondary port group. Eww, sounds like a good definition of spyware, I could go without people knowing exactly what I install and when. I for one wouldn't mind supporting this project. Good for you.. You for one would mind. Yes. Myself and several others I have spoke with. You can't make everybody happy. And the immediately shouting of the equivalent of the word Nazi doesn't help neither. I know that you cannot make everyone happy, The OP was asking for opinions on the matter, I gave my opinion. It was not my attention to call anyone a Nazi so do not put words in my mouth please. -Frank Edwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
fbsd wrote: The fact is the maintainer is all ready being trusted to manage the port so I see no reason NOT to trust him to create the matching package. Because they don't. The port maintainer is trusted to maintain the port ... and then a bunch of people are trusted to audit the ports before the update is allowed in to the ports tree. Or at least, that's how I thought it worked. Even the need of the secure massive package built process is now questionable. The resources and time needed for performing the secure massive package built must impact the release timeline of new FreeBSD releases. Doing away with it may streamline many other different internal release process. New word: secure. The personalised dynamic ports tree is by far the best suggestion so far. A 'most commonly used' ports tree is a daft idea, IMHO, and I fully expect myself to be one of those people who uses quite a few ports that would never make it on to that list. And it's not like I do a lot weird stuff, either. I just think that with the number of fbsd users on this planet, coupled with the number of ports in the tree ... well, there's going to be an awful lot of minorities. Also, I think the idea of having a central database to monitor which ports are used has privacy issues, which will require every port to have a privacy disclaimer and an opt-out option. So much for streamlining. -- Spadge Intoccabile www.fromley.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
fbsd wrote: fbsd wrote: * so working with in that same procedure the maintainer passes the packages to the audit people and they pass it on. No problem with this at all. Thus removing any kind of streamlining to speed up releases of new versions? the port make method will still be there for all ports with limited usage history, it will just not have a package for it because it has limited usage. And this is the crux of the matter. Would phpmyadmin have a php5/mysql4 version? Or do the majority of users use php4 still? And are there more test boxes than there are production servers? Is it fair to say the most commonly used ports are not the most commonly used packages? I would imagine that something like KDE would be a hugely popular package, on account of the sheer size of the beast, but that it wouldn't be the most popular port due to the number of people who don't run a GUI on their system. There is also the fact that you could fairly easily abuse this system if you wanted your software to be included in the 'most commonly used' list, by just hammering the server. There is no privacy issues. Passing cookies is normal and done as matter of fact by most commercial websites and any website that uses php session control makes cookies by default. This is a no-issue issue. Every browser on the planet has the option to disable cookies (in the same way that email clients have the option of indenting quoted text - it's a standard required feature). This is because it is a privacy issue. Different people have different views on what privacy is or isn't, and that's nine tenths of the entire point: we don't get to decide what their privacy levels are, they do. I can totally understand why you think this system would be better for you. I just hope you can understand why it wouldn't be better for everyone, nor even for the majority of people. Now, Marc G. Fournier's dynamic personalised ports tree suggestion ... that's a *real* idea. -- Spadge Intoccabile www.fromley.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On Sunday 14 May 2006 06:08, fbsd wrote: fbsd wrote: The fact is the maintainer is all ready being trusted to manage the port so I see no reason NOT to trust him to create the matching package. Because they don't. The port maintainer is trusted to maintain the port ... and then a bunch of people are trusted to audit the ports before the update is allowed in to the ports tree. Or at least, that's how I thought it worked. If a maintainer tries to put a backdoor or malicious code in a port it's next to impossible to hide it in the source code. How would you propose doing that with a binary? Having the portmanager test every binary that is submitted would slow down the package builds even more. * so working with in that same procedure the maintainer passes the packages to the audit people and they pass it on. No problem with this at all. Even the need of the secure massive package built process is now questionable. The resources and time needed for performing the secure massive package built must impact the release timeline of new FreeBSD releases. Doing away with it may streamline many other different internal release process. The packages are built on a continual basis. The main reason for this is to make sure they build on all systems. Having a package to install is secondary. There is plenty of time after a code freeze for a package run. The personalised dynamic ports tree is by far the best suggestion so far. A 'most commonly used' ports tree is a daft idea, IMHO, and I fully expect myself to be one of those people who uses quite a few ports that would never make it on to that list. And it's not like I do a lot weird stuff, either. I just think that with the number of fbsd users on this planet, coupled with the number of ports in the tree ... well, there's going to be an awful lot of minorities. the port make method will still be there for all ports with limited usage history, it will just not have a package for it because it has limited usage. Also, I think the idea of having a central database to monitor which ports are used has privacy issues, which will require every port to have a privacy disclaimer and an opt-out option. So much for streamlining. There is no privacy issues. Passing cookies is normal and done as matter of fact by most commercial websites and any website that uses php session control makes cookies by default. This is a no-issue issue. Beech -- --- Beech Rintoul - Sys. Administrator - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Alaska Paradise \ / - NO HTML/RTF in e-mail | 201 East 9Th Avenue Ste.310 X - NO Word docs in e-mail | Anchorage, AK 99501 / \ - Please visit Alaska Paradise - http://www.alaskaparadise.com --- pgpLzQKt38xSZ.pgp Description: PGP signature
RE: Has the port collection become to large to handle.
fbsd wrote: fbsd wrote: * so working with in that same procedure the maintainer passes the packages to the audit people and they pass it on. No problem with this at all. Thus removing any kind of streamlining to speed up releases of new versions? *** again you are missing the point. Streaminglining would still occurs because only the most used ports would have packages not the whole collection. The work load would still be reduced. the port make method will still be there for all ports with limited usage history, it will just not have a package for it because it has limited usage. And this is the crux of the matter. Would phpmyadmin have a php5/mysql4 version? Or do the majority of users use php4 still? And are there more test boxes than there are production servers? * yes the port maintainer of phpmyadmin would create 4 packages, One for php5/mysql4, php5/mysql5 php4/mysql4 php4/mysql5 This situation is very small when compared to the over all size of the ports collection. The additional effort expended making additional versions of the package results in greater ease of package use by the package installers * Is it fair to say the most commonly used ports are not the most commonly used packages? I would imagine that something like KDE would be a hugely popular package, on account of the sheer size of the beast, but that it wouldn't be the most popular port due to the number of people who don't run a GUI on their system. * such large GUI desktop packages would be part of the common category for the reason you state. I am sure there are other GUI desktop packages like openoffice that would be included by default. * There is also the fact that you could fairly easily abuse this system if you wanted your software to be included in the 'most commonly used' list, by just hammering the server. read the post you are replying to closer. This was all ready addressed in the previous post. *** There is no privacy issues. Passing cookies is normal and done as matter of fact by most commercial websites and any website that uses php session control makes cookies by default. This is a no-issue issue. Every browser on the planet has the option to disable cookies (in the same way that email clients have the option of indenting quoted text - it's a standard required feature). This is because it is a privacy issue. Different people have different views on what privacy is or isn't, and that's nine tenths of the entire point: we don't get to decide what their privacy levels are, they do. This is absurd statement. On today's public internet no one in their right mind turns off cookies because it causes errors when you try to access commercial websites. All search engines use cookies. Cookies contain no personal information that is why there is no USA federal privacy laws about them. I can totally understand why you think this system would be better for you. I just hope you can understand why it wouldn't be better for everyone, nor even for the majority of people. * Spadge, please refrain from trying to attack people voicing their ideas on this public project mailing list. It only serves to tarnish your own reputation on this list. Again please read the OP if you need to understand the purpose of this thread ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
fbsd wrote: *** again you are missing the point. Streaminglining would still occurs because only the most used ports would have packages not the whole collection. The work load would still be reduced. In your opinion. Roughly what percentage would make it through to the 'most used list' do you think? * yes the port maintainer of phpmyadmin would create 4 packages, One for php5/mysql4, php5/mysql5 php4/mysql4 php4/mysql5 This situation is very small when compared to the over all size of the ports collection. The additional effort expended making additional versions of the package results in greater ease of package use by the package installers * So the People who currently make no packages are now making four of them, and people running mysql3 are expected to manage on their own, and for some reason this reduces the workload? * such large GUI desktop packages would be part of the common category for the reason you state. I am sure there are other GUI desktop packages like openoffice that would be included by default. * Have you considered PCBSD? They've worked long and hard covering exactly this sort of thing, making BSD into a viable graphical desktop/server environment, and done more than a great job of it. For instance ... http://www.pbidir.com/packages.php?code=224 There is also the fact that you could fairly easily abuse this system if you wanted your software to be included in the 'most commonly used' list, by just hammering the server. read the post you are replying to closer. This was all ready addressed in the previous post. *** If you're referring to Of course some precautions in counting the hits to the special purpose FreeBSD website would have to be used to drop attempts by people trying to manipulate the results in favor of some particular port. then I fail to see how this addresses the problem, other than calling for someone else to come up with an idea to fix it. Needless to say, any mechanism short of manual human intervention is going to be unreliable and fairly easy to work around, given the desire to do so. This is absurd statement. On today's public internet no one in their right mind turns off cookies because it causes errors when you try to access commercial websites. All search engines use cookies. Cookies contain no personal information that is why there is no USA federal privacy laws about them. Again, in your opinion. Also, not always my first port of call when looking for great upholders of personal privacy, but that's not a discussion suitable for this thread. Some people disable cookies. Whether they are in their right mind or not is their business, and the option remains in every browser to allow them or not. In much the same way that people can choose to take, or ignore, hints. I can totally understand why you think this system would be better for you. I just hope you can understand why it wouldn't be better for everyone, nor even for the majority of people. * Spadge, please refrain from trying to attack people voicing their ideas on this public project mailing list. It only serves to tarnish your own reputation on this list. Again please read the OP if you need to understand the purpose of this thread ** I was refraining from attacking people. Also, I feel it is fair to say that this thread's history starts somewhere before the start of the thread. Naturally, you may disagree. I fully expect to have approximately no reputation on this list to tarnish or otherwise. I honestly don't think I have said anything even remotely memorable yet. -- Spadge Intoccabile www.fromley.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Has the port collection become to large to handle.
Spadge Your comments are becoming more and more meaningless. You are no longer contributing to the brainstorming of this thread. Your attempt to engage a argument have failed. All posts from you will go unanswered as you are now on my troll kill list. fbsd wrote: *** again you are missing the point. Streaminglining would still occurs because only the most used ports would have packages not the whole collection. The work load would still be reduced. In your opinion. Roughly what percentage would make it through to the 'most used list' do you think? *** no way to even make a guess * * yes the port maintainer of phpmyadmin would create 4 packages, One for php5/mysql4, php5/mysql5 php4/mysql4 php4/mysql5 This situation is very small when compared to the over all size of the ports collection. The additional effort expended making additional versions of the package results in greater ease of package use by the package installers * So the People who currently make no packages are now making four of them, and people running mysql3 are expected to manage on their own, and for some reason this reduces the workload? *** quite trying to put words in my mouth. You know just as well as I that is not what was said. ** * such large GUI desktop packages would be part of the common category for the reason you state. I am sure there are other GUI desktop packages like openoffice that would be included by default. * Have you considered PCBSD? They've worked long and hard covering exactly this sort of thing, making BSD into a viable graphical desktop/server environment, and done more than a great job of it. For instance ... http://www.pbidir.com/packages.php?code=224 I fail to see how this has anything to do with this thread as covered by the OP. Please stay on topic. ** There is also the fact that you could fairly easily abuse this system if you wanted your software to be included in the 'most commonly used' list, by just hammering the server. read the post you are replying to closer. This was all ready addressed in the previous post. *** If you're referring to Of course some precautions in counting the hits to the special purpose FreeBSD website would have to be used to drop attempts by people trying to manipulate the results in favor of some particular port. then I fail to see how this addresses the problem, other than calling for someone else to come up with an idea to fix it. Needless to say, any mechanism short of manual human intervention is going to be unreliable and fairly easy to work around, given the desire to do so. ** yes that is the section you cut out to give meaning to you previous comments. It doesn't take a expert programmer to write the simple code to notice a flood of hits from the same ip address for the same port within some given elapse time period. *** This is absurd statement. On today's public internet no one in their right mind turns off cookies because it causes errors when you try to access commercial websites. All search engines use cookies. Cookies contain no personal information that is why there is no USA federal privacy laws about them. Again, in your opinion. Also, not always my first port of call when looking for great upholders of personal privacy, but that's not a discussion suitable for this thread. Some people disable cookies. Whether they are in their right mind or not is their business, and the option remains in every browser to allow them or not. In much the same way that people can choose to take, or ignore, hints. I can totally understand why you think this system would be better for you. I just hope you can understand why it wouldn't be better for everyone, nor even for the majority of people. * Spadge, please refrain from trying to attack people voicing their ideas on this public project mailing list. It only serves to tarnish your own reputation on this list. Again please read the OP if you need to understand the purpose of this thread ** I was refraining from attacking people. Also, I feel it is fair to say that this thread's history starts somewhere before the start of the thread. Naturally, you may disagree. I fully expect to have approximately no reputation on this list to tarnish or otherwise. I honestly don't think I have said anything even remotely memorable yet. That statement is the only memorable thing you have said so far. LOL * -- Spadge Intoccabile www.fromley.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On 15/05/06, fbsd [EMAIL PROTECTED] wrote: Spadge Your comments are becoming more and more meaningless. You are no longer contributing to the brainstorming of this thread. Your attempt to engage a argument have failed. All posts from you will go unanswered as you are now on my troll kill list. fbsd wrote: *** again you are missing the point. Streaminglining would still occurs because only the most used ports would have packages not the whole collection. The work load would still be reduced. In your opinion. Roughly what percentage would make it through to the 'most used list' do you think? *** no way to even make a guess * * yes the port maintainer of phpmyadmin would create 4 packages, One for php5/mysql4, php5/mysql5 php4/mysql4 php4/mysql5 This situation is very small when compared to the over all size of the ports collection. The additional effort expended making additional versions of the package results in greater ease of package use by the package installers * So the People who currently make no packages are now making four of them, and people running mysql3 are expected to manage on their own, and for some reason this reduces the workload? *** quite trying to put words in my mouth. You know just as well as I that is not what was said. ** * such large GUI desktop packages would be part of the common category for the reason you state. I am sure there are other GUI desktop packages like openoffice that would be included by default. * Have you considered PCBSD? They've worked long and hard covering exactly this sort of thing, making BSD into a viable graphical desktop/server environment, and done more than a great job of it. For instance ... http://www.pbidir.com/packages.php?code=224 I fail to see how this has anything to do with this thread as covered by the OP. Please stay on topic. ** There is also the fact that you could fairly easily abuse this system if you wanted your software to be included in the 'most commonly used' list, by just hammering the server. read the post you are replying to closer. This was all ready addressed in the previous post. *** If you're referring to Of course some precautions in counting the hits to the special purpose FreeBSD website would have to be used to drop attempts by people trying to manipulate the results in favor of some particular port. then I fail to see how this addresses the problem, other than calling for someone else to come up with an idea to fix it. Needless to say, any mechanism short of manual human intervention is going to be unreliable and fairly easy to work around, given the desire to do so. ** yes that is the section you cut out to give meaning to you previous comments. It doesn't take a expert programmer to write the simple code to notice a flood of hits from the same ip address for the same port within some given elapse time period. *** This is absurd statement. On today's public internet no one in their right mind turns off cookies because it causes errors when you try to access commercial websites. All search engines use cookies. Cookies contain no personal information that is why there is no USA federal privacy laws about them. Again, in your opinion. Also, not always my first port of call when looking for great upholders of personal privacy, but that's not a discussion suitable for this thread. Some people disable cookies. Whether they are in their right mind or not is their business, and the option remains in every browser to allow them or not. In much the same way that people can choose to take, or ignore, hints. I can totally understand why you think this system would be better for you. I just hope you can understand why it wouldn't be better for everyone, nor even for the majority of people. * Spadge, please refrain from trying to attack people voicing their ideas on this public project mailing list. It only serves to tarnish your own reputation on this list. Again please read the OP if you need to understand the purpose of this thread ** I was refraining from attacking people. Also, I feel it is fair to say that this thread's history starts somewhere before the start of the thread. Naturally, you may disagree. I fully expect to have approximately no reputation on this list to tarnish or otherwise. I honestly don't think I have said anything even remotely memorable yet. That statement is the only memorable thing you have said so far. LOL * -- Spadge Intoccabile www.fromley.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Keep the ports tree how it is, as others have said the size is small on modern hard drives and bandwidth trivial, once the initial ports tree is in place keeping it up to date needs very
Re: Has the port collection become to large to handle.
On Sun, May 14, 2006 at 02:04:55PM +0300, Panagiotis Astithas wrote: I believe that one solution to the scalability problem of creating and maintaining updated packages, would be to decentralize it more. Each time I submit an update for one of the ports I maintain, I've already build the relevant packages, as a QA measure. There should be no need to wait for the ports cluster to build the official version, instead of using my own, modulo perhaps the higher quality assurance you'd get from Kris's build infrastructure. You have built the package for one build environment (buildenv). There are 12. See http://portsmon.freebsd.org/portsoverall.py. mcl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
fbsd wrote: Spadge Your comments are becoming more and more meaningless. You are no longer contributing to the brainstorming of this thread. Your attempt to engage a argument have failed. All posts from you will go unanswered as you are now on my troll kill list. *joy* Agreeing with one suggestion to potentially improve the ports system, whilst not agreeing with every suggestion makes me a troll, just because I take the time to bother replying to your posts? I'll not be making that mistake again later. The ports system is very dear to me, it's something that I use all the time; 4 years into my experience with FreeBSD and it still impresses me. Does this mean I think it's perfect and can't be improved upon from where it is now? No, of course not. Do I consider myself qualified to suggest overhauling the entire system just because it fails to meet my needs in one respect or another? No, it does not. Do I feel that I should be allowed to voice my opinions in a thread which called for the users of FreeBSD and its ports system to voice their opinions? Certainly, yes I do. So the People who currently make no packages are now making four of them, and people running mysql3 are expected to manage on their own, and for some reason this reduces the workload? *** quite trying to put words in my mouth. You know just as well as I that is not what was said. ** I was just replying to the words you used, I'm sorry if I missed some meaning or another. Have you considered PCBSD? They've worked long and hard covering exactly this sort of thing, making BSD into a viable graphical desktop/server environment, and done more than a great job of it. For instance ... http://www.pbidir.com/packages.php?code=224 I fail to see how this has anything to do with this thread as covered by the OP. Please stay on topic. ** You fail to see how a link to a group that creates and distributes a FreeBSD based system with a different kind of packaging system that has all the (what they consider to be) most popular ports built into easy to get and install packages has anything to do with the original post and the discussion that followed? OK then. I think that as long as someone relies on other people to compile packages for them, things won't be tailored to meet the needs of that person, specifically where dependency versions and compile-time options are concerned, and that whatever is done to change this it will always remain true for someone, at least. This is specifically what the ports system is great for, and why there is a base make.conf for global make arguments, and something that utilities like portupgrade exist for, to make easier for the user: to allow someone who is installing or updating any software through the ports tree to pick up arguments like WITH_APACHE2, so that their system then doesn't go and try to install apache13 instead or as well because that is listed as the base dependency version in the port. Now, all that said, have a look at PCBSD's PBI system, it pretty much does what you wanted from the package system from the start. And for those people who don't want to compile their own stuff, but who still want something that isn't quite the default build, there's a request mechanism in place. If you're referring to Of course some precautions in counting the hits to the special purpose FreeBSD website would have to be used to drop attempts by people trying to manipulate the results in favor of some particular port. then I fail to see how this addresses the problem, other than calling for someone else to come up with an idea to fix it. Needless to say, any mechanism short of manual human intervention is going to be unreliable and fairly easy to work around, given the desire to do so. ** yes that is the section you cut out to give meaning to you previous comments. It doesn't take a expert programmer to write the simple code to notice a flood of hits from the same ip address for the same port within some given elapse time period. *** And any script kiddie with even a modest botnet could knock up a simple script to throw the figures way out of kilter. Someone with a slightly less modest botnet could have a much larger impact. I was refraining from attacking people. Also, I feel it is fair to say that this thread's history starts somewhere before the start of the thread. Naturally, you may disagree. I fully expect to have approximately no reputation on this list to tarnish or otherwise. I honestly don't think I have said anything even remotely memorable yet. That statement is the only memorable thing you have said so far. LOL * Cute. -- Spadge Intoccabile www.fromley.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
First of all, please don't cross post. On Saturday 13 May 2006 10:28, fbsd wrote: To all question list readers; Now with 14576 ports in the collection where do you draw the line that its too large to be downloading the whole collection when you just use 10 or 20 of them? The port collection is growing at a ever increasing rate per month. The mass majority of the ports are so special purpose that only a very few people have need of them. Sure there are ways to limit the categories you select to download, but still the size of the most used categories is too large and loaded with ports not commonly used by the general user. So people them use the packages. But the problem with the packages is they are not updated every time changes are made to the port they were created from. Also packages that have dependants like php4/php5 or mysql4/mysql5 are not being updated to use the newer versions of those dependants as they come out. I for one think the port/package collection has already grown to large to handle in it's present state. Users are consuming massive bandwidth to download and it consumes a very large chunk of disk space. Saying nothing about the wasted resources consumed to back it up repeatedly. I have gone to using the package version for everything and only downloading the ports config files for packages that I need to compile from scratch to change some add on function. This methodology has worked fine since FreeBSD version 3.0 as I used each new release of FreeBSD up to 6.1. Now in 6.1 there is problems with packages that have not been recreated using the new system make file. This problem is caused by there being no mandatory requirement on the ports maintainers to recreate the packages any time one of the dependants change or when changes are made to the canned make process or when dependants show up as broken. Yes I know what a large task this is and that it requires a lot of run time to accomplish. So my question is how do we users make our needs known to the ports maintainer group so that will seriously address the problem of the packages being outdated? Are there other people on this list who are dissatisfied with the packages and the problems associated with using packages and ports mixed together? What are your thoughts about requesting the ports group to create a new category containing just the ports most commonly used including their dependents and making this general category the default used to download. This would be a much smaller sized download containing everything necessary to build the most used ports. Many of the dependents are used over and over by many different port applications. This will never work. I doubt if you could find agreement between two users as to what to include. We really don't need to go down the micro$oft we decide what you need approach to our ports. The binary update question has been discussed at length in these forums. There is nothing to stop you from making a local ports tree to better suit your situation. But don't complain if you find conflicts with the port tools and/or ports. The ports that are considered universal are already included and maintained as part of the base system. As was stated in earlier replies, you need the complete ports tree otherwise you are on your own. As a port maintainer, it's quite enough work to keep things in sync with one ports tree without having to also worry about a second convenience tree that will only benefit a few users. The lack of willingness on your part to download the complete tree does not constitute a problem on our end. Beech This new category would them be given priority in keeping their packages up to date. Could even take this idea one step further and say that only ports in this category will have packages built and keep up to date. All ports not in this special category will not have packages built at all. I think this would help the port group to better manager their people resources and serve the needs of the user community better. Another idea I would like to throw out to the list is how about requesting the ports group to add a function to packages so the installer of the package can select what version of the dependent components should be included in the install. Much like make config does in the ports system? The packages system already automatically launches the download of dependent packages so why not give the installer the option to select which version of the dependent to fetch. Like in php4/5 or mysql4/5 or apache 13/20. This way the package is more flexible and the port maintainer does not have to build a different version of the parent package for each version of the dependant which is available. The whole idea behind this post is to give the general users who reads this questions list an opportunity to brainstorm about ways to make the ports/package collection better and easier to use.
Re: Has the port collection become to large to handle.
fbsd wrote: To all question list readers; Now with 14576 ports in the collection where do you draw the line that its too large to be downloading the whole collection when you just use 10 or 20 of them? snip All feedback welcome. 1. Cvsup 2. Prozac /me rolls eyes, again Kevin Kinsey -- If you see an onion ring -- answer it! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On Saturday 13 May 2006 10:28, fbsd wrote: To all question list readers; Now with 14576 ports in the collection where do you draw the line that its too large to be downloading the whole collection when you just use 10 or 20 of them? The port collection is growing at a ever increasing rate per month. The mass majority of the ports are so special purpose that only a very few people have need of them. Sure there are ways to limit the categories you select to download, but still the size of the most used categories is too large and loaded with ports not commonly used by the general user. So people them use the packages. But the problem with the packages is they are not updated every time changes are made to the port they were created from. Also packages that have dependants like php4/php5 or mysql4/mysql5 are not being updated to use the newer versions of those dependants as they come out. I for one think the port/package collection has already grown to large to handle in it's present state. Users are consuming massive bandwidth to download and it consumes a very large chunk of disk space. Saying nothing about the wasted resources consumed to back it up repeatedly. I have gone to using the package version for everything and only downloading the ports config files for packages that I need to compile from scratch to change some add on function. This methodology has worked fine since FreeBSD version 3.0 as I used each new release of FreeBSD up to 6.1. Now in 6.1 there is problems with packages that have not been recreated using the new system make file. This problem is caused by there being no mandatory requirement on the ports maintainers to recreate the packages any time one of the dependants change or when changes are made to the canned make process or when dependants show up as broken. Yes I know what a large task this is and that it requires a lot of run time to accomplish. Compiling a package is trivial, but it would be a security nightmare to have maintainers be responsible for it. All packages are built in an environment known to be secure. If you really want to help, consider donating some hardware to the build cluster. So my question is how do we users make our needs known to the ports maintainer group so that will seriously address the problem of the packages being outdated? Are there other people on this list who are dissatisfied with the packages and the problems associated with using packages and ports mixed together? What are your thoughts about requesting the ports group to create a new category containing just the ports most commonly used including their dependents and making this general category the default used to download. This would be a much smaller sized download containing everything necessary to build the most used ports. Many of the dependents are used over and over by many different port applications. This new category would them be given priority in keeping their packages up to date. Could even take this idea one step further and say that only ports in this category will have packages built and keep up to date. All ports not in this special category will not have packages built at all. I think this would help the port group to better manager their people resources and serve the needs of the user community better. Another idea I would like to throw out to the list is how about requesting the ports group to add a function to packages so the installer of the package can select what version of the dependent components should be included in the install. Much like make config does in the ports system? The packages system already automatically launches the download of dependent packages so why not give the installer the option to select which version of the dependent to fetch. Like in php4/5 or mysql4/5 or apache 13/20. This way the package is more flexible and the port maintainer does not have to build a different version of the parent package for each version of the dependant which is available. The whole idea behind this post is to give the general users who reads this questions list an opportunity to brainstorm about ways to make the ports/package collection better and easier to use. This may help the ports group in understanding the needs and direction we the users would like to see the management of the collection to take. If we don't speak up they will just think things are ok as they are now. FreeBSD is a public project. The ports group are not the only users who can give input about the direction and policies concerning the future of the ports/package collection. All feedback welcome. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- ---
RE: Has the port collection become to large to handle.
As a port maintainer, it's quite enough work to keep things in sync with one ports tree without having to also worry about a second convenience tree that will only benefit a few users. This post says nothing about a second convenience tree. Talking about a (to use your term) convenience category which fits nicely into the category schema all ready being used. Please read the original post more closely so your comments pertains to what was posted. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On Sat, May 13, 2006 at 02:28:49PM -0400, fbsd wrote: Users are consuming massive bandwidth to download and it consumes a very large chunk of disk space. Saying nothing about the wasted resources consumed to back it up repeatedly. cvsup uses a relatively tiny amount of bandwidth, since only changes are being sent. Personally, I have a local cvsup mirror from which my other machines get their updates, so really, there isn't any wastage. As for backing it up... well, that's just silly. The ports collection and its entire history is always available and mirrored to countless machines. If bandwidth really is a problem, then it is possible - but not necessarily a good idea - to check out individual ports via CVS. What are your thoughts about requesting the ports group to create a new category containing just the ports most commonly used including their dependents and making this general category the default used to download. This would be a much smaller sized download containing everything necessary to build the most used ports. Many of the dependents are used over and over by many different port applications. Exactly which ports are commonly used, and how do you track this? Apache? PHP? We have several versions of each; four or five versions of the big databases, and these all have dependencies, which have their own dependencies, and so on. The common category would have to be pretty large, catering for enough users to be worthy of its name, and containing all the possible dependencies. As soon as you need a port that isn't in the common category, you're out of luck: the rest of the tree needs to be downloaded. and say that only ports in this category will have packages built and keep up to date. All ports not in this special category will not have packages built at all. I think this Bad idea. Again, as soon as someone wants a package not in the special list, they lose out. Besides, building packages serves another purpose: quality assurance. Building packages ensures that the ports can be built correctly, and serves as a tool for testing the base system. Another idea I would like to throw out to the list is how about requesting the ports group to add a function to packages so the installer of the package can select what version of the dependent components should be included in the install. This would only work for runtime dependencies. Most software is compiled differently depending on what versions of things are available at the time of compilation. -- Shaun Amott [ PGP: 0x6B387A9A ] Scientia Est Potentia. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On Sat, 2006-May-13 21:39:46 +0100, Shaun Amott wrote: If bandwidth really is a problem, then it is possible - but not necessarily a good idea - to check out individual ports via CVS. This is not supported. If you want to build ports from source, you _must_ have a complete and consistent ports tree. Otherwise you are on your own. -- Peter Jeremy ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On Sat, May 13, 2006 at 02:28:49PM -0400, fbsd wrote: I for one think the port/package collection has already grown to large to handle in it's present state. I suspect you are in the minority here. Users are consuming massive bandwidth to download and it consumes a very large chunk of disk space. No, a snapshot of the ports tree is only about 30 Mb. ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ I think you'll find cvsup's bandwidth usage is pretty minimal. Disk space is cheap. The ports tree decompresses to about 210 Mb. That's less than 0.01% of a modern ~$100 average-sized 80 Gb hard drive supplied with most desktop PCs. Saying nothing about the wasted resources consumed to back it up repeatedly. Unnecessary. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
At 2:28 PM -0400 5/13/06, fbsd wrote: To all question list readers; Now with 14576 ports in the collection where do you draw the line that its too large to be downloading the whole collection when you just use 10 or 20 of them? This is a good question. For all those people who want to roll their eyes and ignore this question, please answer it. Where *DO* you draw the line? Obviously it's not at 10,000 ports. Will it be 20,000? 50,000? How many programs exist? Will every single program known to man eventually be in the ports collection? How hopeless is that? And if not, then Where do you draw the line?. What are your thoughts about requesting the ports group to create a new category containing just the ports most commonly used including their dependents and making this general category the default used to download. Unfortunately, this is the wrong solution. I'm sure you will love this *IFF* (that means if and ONLY if) all of *YOUR* ports are in that category of important ports. We have 15,000 ports because every single one of those ports has some users who think that specific port is important. While I'm sure that some ports will be willing to be in the second tier category, I suspect you'll still have thousands of ports with hundreds of thousands of users who will be personally insulted if someBastard refused to include their favorite port in the important category. I doubt you will find anyone who wants to volunteer for the role of someBastard, because that is certainly the only name which will be used to describe whoever chooses which ports are in the special category. We need some more dramatic restructuring of ports to really solve the issue. Your suggestion is a very small bandaid, and will just result in more fighting and ill-will instead of solving anything. All of this is just my opinion, of course. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Shaun Amott writes: cvsup uses a relatively tiny amount of bandwidth, since only changes are being sent. Personally, I have a local cvsup mirror from which my other machines get their updates, so really, there isn't any wastage. Back when I had a 28.8 dialup connection, I updated the ports tree daily. No hassle; no sweat. Distfiles, now were a different matter Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On Sat, 13 May 2006, Garance A Drosihn wrote: At 2:28 PM -0400 5/13/06, fbsd wrote: To all question list readers; Now with 14576 ports in the collection where do you draw the line that its too large to be downloading the whole collection when you just use 10 or 20 of them? This is a good question. For all those people who want to roll their eyes and ignore this question, please answer it. Where *DO* you draw the line? Obviously it's not at 10,000 ports. Will it be 20,000? 50,000? How many programs exist? Will every single program known to man eventually be in the ports collection? How hopeless is that? And if not, then Where do you draw the line?. Why draw a line? Why not just improve installing from ports so that you don't have to download the whole ports collection to do so? For those with 'always on' internet connections, this should be *too* difficult ... all you'd need to do is: download ports-base, which would have to include INDEX type: make fetch-postfix and let the make system be smart enough to know to pull down mail/postfix ... something like a 'fetch' of a postfix.tar.gz tarball from the closest ftp server, untar it in /usr/ports/mail/postfix, and that seeds your ports tree ... go into mail/postfix and type 'make install' ... have the make system smart enough that if a dependency isn't found, first thing it does is grabs down that dependency to make it, recursively ... Now, your /usr/ports will only contain those ports that you actually use ... a 'self-learning ports tree', of sources ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Garance A Drosihn wrote: Unfortunately, this is the wrong solution. I'm sure you will love this *IFF* (that means if and ONLY if) all of *YOUR* ports are in that category of important ports. We have 15,000 ports because every single one of those ports has some users who think that specific port is important. While I'm sure that some ports will be willing to be in the second tier category, I suspect you'll still have thousands of ports with hundreds of thousands of users who will be personally insulted if someBastard refused to include their favorite port in the important category. I doubt you will find anyone who wants to volunteer for the role of someBastard, because that is certainly the only name which will be used to describe whoever chooses which ports are in the special category. How about implement a system where by ports register their usage to a central server. This will give us some very useful stats about port usage and after some time this is examind and all ports whos usage falls under a given measure ( to be decided again by stats ) said port is moved to a secondary port group. We could also use this info to prune ports not getting any use at all. In addition to that a method of syncing ports indivitually might be an alternative way to go. That way instead of syncing the many thousands of ports to compile up the latest version of XXX you would only have to download the port you wanted and any dependencies. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
Steven Hartland wrote: Garance A Drosihn wrote: Unfortunately, this is the wrong solution. I'm sure you will love this *IFF* (that means if and ONLY if) all of *YOUR* ports are in that category of important ports. We have 15,000 ports because every single one of those ports has some users who think that specific port is important. While I'm sure that some ports will be willing to be in the second tier category, I suspect you'll still have thousands of ports with hundreds of thousands of users who will be personally insulted if someBastard refused to include their favorite port in the important category. I doubt you will find anyone who wants to volunteer for the role of someBastard, because that is certainly the only name which will be used to describe whoever chooses which ports are in the special category. How about implement a system where by ports register their usage to a central server. This will give us some very useful stats about port usage and after some time this is examind and all ports whos usage falls under a given measure ( to be decided again by stats ) said port is moved to a secondary port group. Eww, sounds like a good definition of spyware, I could go without people knowing exactly what I install and when. We could also use this info to prune ports not getting any use at all. Then when someone does need it, it wont be there, and will have to be re-ported. In addition to that a method of syncing ports indivitually might be an alternative way to go. That way instead of syncing the many thousands of ports to compile up the latest version of XXX you would only have to download the port you wanted and any dependencies. This is a neat idea that Marc brought up. Perhaps a dynamic ports tree is the answer. With an up to date INDEX, It probably wouldn't be hard to patch the ports system to download JUST the ports you need, and their dependencies. We would just have to decide on the method to do this. I suppose something like cvsup, or portsnap could be utilized to checkout single ports. But then again, after that, whats the point of even having sub directories for ports? Why not just have it download the framework, build the port, and delete everything. Now its starting to resemble debians apt-get. *shrug* -Frank ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
On 5/13/06, Frank Laszlo [EMAIL PROTECTED] wrote: We could also use this info to prune ports not getting any use at all. Then when someone does need it, it wont be there, and will have to be re-ported. In addition to that a method of syncing ports indivitually might be an alternative way to go. That way instead of syncing the many thousands of ports to compile up the latest version of XXX you would only have to download the port you wanted and any dependencies. This is a neat idea that Marc brought up. Perhaps a dynamic ports tree is the answer. With an up to date INDEX, It probably wouldn't be hard to patch the ports system to download JUST the ports you need, and their dependencies. We would just have to decide on the method to do this. I suppose something like cvsup, or portsnap could be utilized to checkout single ports. But then again, after that, whats the point of even having sub directories for ports? Why not just have it download the framework, build the port, and delete everything. Now its starting to resemble debians apt-get. *shrug* The resemblance is not, in and of itself, a bad thing. Is there anything preventing someone from making a portupgrade-like tool that uses only tmp, a /ports dir on an ftp site and a bit of intelligence regarding dependency resolution? Correct me if I'm wrong, but I'm not seeing any technical reasons this couldn't be done. (okay... so your equivelent of portversion might get a little more complicated or potentially wierd) I would submit, however, that it hasn't been done simply because it isn't needed. 210 mb is laughably insignificant on any system I would build ports. Although you can say that the number of ports is increasing, disk size is doing the same; I'm unconvinced that the ports tree size is growing fast enough to outpace either the expansion of high speed networks or modern disks. This may change of course, but we would likely have some warning. :) Regards, Joe Kerian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
