> my experiences of slow and nightmarishly error-ridden port updatesI have no intention to bash FreeBSD or ports but ports is certainly not without problems. It's annoying but not a reason to use Ubuntu! Get a grip, man! ;-)> I know there are users who have operated without such problemsI think if you use the i386 architecture and the common ports you are less likely to find something before somebody else finds it and it gets fixed. If you use any other platform you are likely to find problems with ports and this gets amplified if you use nonstandard (read stuff not everybody uses) ports. I have found several ports broken for many releases in a row. Other ports aren't supported on certain target architectures but the build doesn't tell you that until after it has run for a couple of hours downloading huge source tarballs and compiling them only to give you a nastygram "Sorry this port is not available on AMD64" of something like that. I understand not every port maintainer can test on every arch but come on, for stuff that you know doesn't work can't you check at the beginning and stop rather than put out a message when the build breaks?
Em Sex, Mar?o 2, 2012 11:35, Nomen Nescio escreveu:>> my experiences of slow and nightmarishly error-ridden port updates > > I have no intention to bash FreeBSD or ports but ports is certainly not > without problems. It's annoying but not a reason to use Ubuntu! Get a > grip, man! ;-) > >> I know there are users who have operated without such problems >> > > I think if you use the i386 architecture and the common ports you are > less likely to find something before somebody else finds it and it gets > fixed. If you use any other platform you are likely to find problems with > ports and this gets amplified if you use nonstandard (read stuff not > everybody uses) ports.with some good luck may be ... ports need some kind of disaster management for example, certain ports depending on perl, install or upgrade fine when using portupgrade or portinstall and are satisfied with let's say perl-8.9 then you use pkg_add, or -P[P] switch and the same port looks for perl.12.4 and bumps it into the system careless, not even checking if there is another perl already no way using batch on ports today unless you like to get screwed and never turn your eyes away from screen .... I do not need to say more, you all know that and I can understand the frustration of whom is gotten caught by this mess> I have found several ports broken for many releases > in a row. Other ports aren't supported on certain target architectures but > the build doesn't tell you that until after it has run for a couple of > hours downloading huge source tarballs and compiling them only to give you > a nastygram "Sorry this port is not available on AMD64" of something like > that. I understand not every port maintainer can test on every arch butcome on, then the port should not be there for this architecture ... or it is and works or it is not or do we have new standards now as 0|0.5|1 or is it still 0|1 ?> come on, for stuff that you know doesn't work can't you check at the > beginning and stop rather than put out a message when the build breaks?some fine ports are compiling fine, go through the whole process and screw all up at the install process, they already run pkg_delete, do not find the dependency, do some stuff and bail out, at the end portupgrade confirm success but they do not got installed but de-installed, as present some dependencies are messed up ... :) so as it is, better grab the original sources and compile your stuff on your own and stay "far" away from ports -- Jo?o Martins (JoaoBR) Infomatik Development Team http://wipserver.matik.com.br +55 11 4249.2222
On Fri, Mar 02, 2012 at 03:35:24PM +0100, Nomen Nescio wrote:> If you use [!i386] you are likely to find problems with ports and > this gets amplified if you use nonstandard (read stuff not everybody uses) > ports.Fair enough.> I have found several ports broken for many releases in a row.These are bugs. Please report them via PRs.> Other ports aren't supported on certain target architectures but the build > doesn't tell you that until after it has run for a couple of hoursThose are also bugs. Please send PRs for those, as well. I am particularly concerned about amd64 in this regard (although I am actually only myself doing the package runs for sparc64 and powerpc). We continually try to adjust the metadata for ports to indicate where they will and will not run, based on the output of pointyhat runs. (OTOH pointyhat runs the src tree from "the oldest supported minor release on each branch", so this may be a clue .) For those interested in investigating the metadata as seen by these package build runs, they are available. For instance: http://pointyhat.freebsd.org/errorlogs/amd64-9-latest/duds.verbose Substitute {i386|sparc64|powerpc} for "amd64" and {7|8} for "9" to look at the others. Note that I haven't done any ia64 builds in quite a long time. Also note that for sparc64 and powerpc, I no longer try to do 7. Finally, we haven't done many runs on 10 yet. You can see the overall state of the various package builds at: http://pointyhat.freebsd.org/errorlogs/packagestats.html whose "skipped" links will take you to the duds.verbose files. mcl
Bas Smeelen wrote:> On 03/02/2012 07:42 PM, H wrote: >> Doug Barton wrote: >>> ... and here is the crux of the problem. The vast majority of our >>> developers don't use FreeBSD as their regular workstation. So it has >>> increasingly become an OS where changes are being lobbed over the wall >>> by developers who don't run systems that those changes affect. That's >>> no way to run a railroad. Doug >> wow >> >> since it is not April 1st it must be revelation's day ...:) >> >> is this then the bottomline ? >> >> if [ $using_ports=YES ]; get_screwed($big_time); fi >> >> > Hey people > > There are still a lot of us which might not be smart enough or lack > the resources to help you debug issues but we still use and depend on > FreeBSD, and we test, and hopefully give you some debugging hints > > I have some production servers running on STABLE and even some on > CURRENT to stress our developers, but most run RELEASE and use > freebsd-update > > Keep up the good work, it makes me a more confident sysadmin > Ports is the best thing happening to me after going through al the apt > and other stuffyou talk like the wind blows my friend ... remembering your own most recent words in another occasion what certainly do not match your last sentence ...>/ On Mon, Jan 30, 2012 at 3:58 PM, Bas Smeelen <b.smeelen at ose.nl <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>> wrote:/>/ />/ > On Mon, 30 Jan 2012 12:52:07 -0500 />/ > David Jackson <djackson452 at gmail.com <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>> wrote: />/ > />/ > > I have tried endlessly to no avail to upgrade binary the packages />/ > > on Freebsd to the latest version. I have tried: />/ > > /...>/ > >/>/ > > All fail miserably and totally and have left the system in an />/ > > unuseable state. />/ > /....>//>/ />/ I wish to use binary packages and I specifically do not want to />/ compile anything, it tends to take far too long to compile programs />/ and would rather install some packages and have it all work right />/ away. Binary packages are a big time saver and are more efficient. It />/ should be easy for FreeBSD to make it easy to install the most recent />/ versions of all binary packages, its beyond belief they cannot pull />/ off such a simple ans straight forward, and basic part of any OS. / -- H -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120303/d100a34f/signature.pgp