Re: Time to mark portupgrade deprecated?
Chris Brennan wrote: On 7/26/2011 3:28 PM, RW wrote: It seems more reasonable than the idea that most people using FreeBSD are doing so despite being very unhappy with FreeBSD ports. If that's= really true then we should give Beastie nipple-clamps and a ball-gag to= better appeal to our key demographic. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org= +1 just because the thought of that is funny as hell! As a testimonial to the diabolical nature of FreeBSD yesterday i have installed a PC with FreeBSD-8.2 RELEASE, using the distributed packages (pkg_add -r). When installing gimp, something went south. After some checks it was avahi-app which refused to install, the reason being that pw groupadd -n avahi failed, with the message: group disappeared during update This from /usr/src/usr.sbin/pw/pw_group.c line 271. How is it that such an error, perhaps due to some concurrent access bug, happens in such an irregular way that it is still present since many years? In my installation, several other packages used pw to add to the group and passwd files (hald, etc.) but the error was triggered only by avahi-app, on the other hand it was 100% reproductible for avahi-app. I have seen this problem many times in the past. The only way i was able to proceed was to run pkg_add -I -r avahi-app after that the other dependencies of gimp and gimp itself installed OK. I don't remember that this error was blocking in this way in the past, but it is very worrisome, i don't see a beginner being able to cope with such problem. Still another problem in my installation i have an inn server which sucks news via newsx. Inn installed OK but newsx doesn't appear on the freebsd repository. I try to compile newsx, of course it fails. The reason? the inn installation lacks all the configuration files under /usr/local/news/etc ! More than that the conf files appear nowhere on the machine! How a user is supposed to figure out how to write such files without the models at hand? I have installed inn several times, i have never seen that. Some maintainer has found judicious to remove the conf files (perhaps to avoid overwriting a preexisting installation, but this is the bad way to solve the problem). Anyways, without etc/inn.conf, newsx cannot compile, since it picks its own configuration from inn.conf. So by doing this change the inn maintainer has broken newsx inadvertently, and of course no one noticed. This is emblematic of many other ports which are mismanaged, introduce tons of unnecessary dependencies which complicate everything, etc. For example, installing the port xorg installed things such as pyton and ruby which have zero relation with the problem at hand. It also installed perl but this is required for autoconfiguration of the server, i think. On the bright side, installing xorg produced a working X11 display without any configuration except running dbusd and hald. I have at least one positive point to report, for the first time i see printing working in wxMaxima, in the past either it didn't work at all or coredumped. So someone has understood the printing problem in the wx toolkit, this is nice. This post is ways too long, but i hope more informative that comments such as Nuts ushered by some phd student who apparently value himself at tremendous heights. As to the poster objection, one may very well use FreeBSD for some other qualities, even if one is not happy with the state of the ports system. And to the more general objection that all this is unrelated to the thread subject, portupgrade, it is *extremely* related, because no upgrading tool can work, be it portupgrade, portmaster, or whatever, in the presence of the sorts of bugs i have described above in the basic ports system. An obvious flaw of portupgrade is that it is very slow, other than that i think it is a pretty good program. Similarly portmaster is a brilliant example of shell scripting and works OK as far as i can see. The real problems are in the ports system itself. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
nscd vs. ports that add user/group (Was: Time to mark portupgrade deprecated?)
Test Rat ttse...@gmail.com writes: As a testimonial to the diabolical nature of FreeBSD yesterday i have installed a PC with FreeBSD-8.2 RELEASE, using the distributed packages (pkg_add -r). When installing gimp, something went south. After some checks it was avahi-app which refused to install, the reason being that pw groupadd -n avahi failed, with the message: group disappeared during update [...] Did you have nscd(8) running at the time? Try invalidating its cache. Nevermind previous patch. This one actually works. %% it's still an ugly hack Index: usr.sbin/pw/pwupd.c === --- usr.sbin/pw/pwupd.c (revision 224499) +++ usr.sbin/pw/pwupd.c (working copy) @@ -191,6 +191,7 @@ pw_update(struct passwd * pwd, char const * user, } } } + system(nscd -I passwd 2/dev/null 2); return rc; } Index: usr.sbin/pw/grupd.c === --- usr.sbin/pw/grupd.c (revision 224499) +++ usr.sbin/pw/grupd.c (working copy) @@ -148,6 +148,7 @@ gr_update(struct group * grp, char const * group, } if (grbuf != NULL) free(grbuf); + system(nscd -I group 2/dev/null 2); return l; } %% ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: nscd vs. ports that add user/group (Was: Time to mark portupgrade deprecated?)
On Sat, Jul 30, 2011 at 04:02:55PM +0400, Test Rat wrote: Did you have nscd(8) running at the time? Try invalidating its cache. Nevermind previous patch. This one actually works. You may be perfectly right, i think i have added nscd to the installation after having added hald, etc. but before adding avahi-app. However i have seen such problems in the past, before the introduction of nscd, as far as i remember. %% it's still an ugly hack Index: usr.sbin/pw/pwupd.c === --- usr.sbin/pw/pwupd.c (revision 224499) +++ usr.sbin/pw/pwupd.c (working copy) @@ -191,6 +191,7 @@ pw_update(struct passwd * pwd, char const * user, } } } + system(nscd -I passwd 2/dev/null 2); return rc; } Index: usr.sbin/pw/grupd.c === --- usr.sbin/pw/grupd.c (revision 224499) +++ usr.sbin/pw/grupd.c (working copy) @@ -148,6 +148,7 @@ gr_update(struct group * grp, char const * group, } if (grbuf != NULL) free(grbuf); + system(nscd -I group 2/dev/null 2); return l; } %% Many thanks for the suggestion. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Jul 30, 2011, at 4:03 AM, Michel Talon wrote: [ ... ] The real problems are in the ports system itself. You've said this before. Come to think of it, you've said this so often that I've lost count of the number of times you've repeated the point. However, flogging the same dead horse over and over does not constitute forward progress. Speaking of which, if you'd spent some of this time filing bug reports instead, then it's very likely that at least some of the issues you claim to keep running into would be fixed by now. However, as far as I can tell from a quick search, you've never filed even one FreeBSD PR? Methinks 'tis time to change your approach: The clock upbraids me with the waste of time. Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Jerry wrote: While we are on the subject of port management tools, I still use portmanager when a version bump on a port requires that a massive number of dependencies be rebuild. I have had all too many instances when both portupgrade and portmaster simply bombed out and left me with only a partially updated system, and in many cases, a virtually useless one. Portmanager would simple get the job done right the first time. It might be overkill for one or two port upgrades; however, it works fine on massive projects that seem to bewilder the other two competing contenders. The p5-libwww-5* example in the case of portmaster being a perfect example. This subject of port management tools is a subject i have been much interested in some years ago, and i must say that the problems which seem to surface now in the general consensus, i had discussed them without any echo at the time. Having a system partially updated hence requiring a lot of work to fix with portupgrade happened to me several times. Horrific slowness of portupgrade was perfectly obvious years ago. I think most of the problems come from errors in the ports themselves so are unfixable through ameliorations in the upgrade tools. I think only a more rigorous management of the ports, i mean something like the separation between unstable, testing, stable in Debian, with rigorous procedures for going from one state to the better one could cure this problem, but at the expense of slowing the development. More importantly, only a procedure centered around *binary* packages could possibly lead to a guaranteed decent state of the ports. Centering things around source code can only lead to confusion, incessant messing by both developers and users with various options etc. which can only destabilize the system. Anyways, to come back to port management tools i don't know how portmanager works, but i think that both portupgrade and portmaster have a fundamental flaw in that they both work locally, upgrading one port after another until the job is finished, which means that the state of the machine is constantly modified, possibly into a broken state, without any possibility for the user to know beforehand that he is headed to failure. A proper tool should do a first pass describing exactly the initial state and the final state so that the end user can choose to upgrade or not. This is what Debian apt-get (or aptitude) does, it describes before any destructive action begins what will be removed, what will be installed. This can only work reliably if you have binary packages, otherwise you can never be sure that a source port will compile. The only *BSD i am aware of that has moved in that direction is OpenBSD. From what i hear, people are happy with the management of ports in OpenBSD, while most of people i hear are very unhappy with FreeBSD ports. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Tue, 2011-07-26 at 11:27 +0200, Michel Talon wrote: [ Stuff about how we should move to binary packages because Debian. ] Sure, why not kill one of the biggest strengths FreeBSD is known for while we're at it... Two questions: Who will provide the infrastructure to build me all of my packages the day/hour/moment moment I need them and constantly build me the i386, amd64, athlon-tbird optimized, k8-sse3 optimized, -O2 and -O3 optimized, intel-core optimized, and intel-p3 optimized batches for all of my machines? Who will constantly build and maintain my custom set of binary packages and all their dependencies built with the exact specific OPTIONS that I need and without the components that I don't want? Because I'm in no mood for experiencing the hell of Linux users that can't even remove ALSA from their systems and fully switch to 4Front OSS, as all of their distro's packages are built against ALSA anyway, in some cases even exclusively, with OSS support completely removed, because why not. So no, thanks, I'm one of those that are perfectly happy with my fundamentally flawed source-based ports. Take that away and you might as well as kill FreeBSD for me, and probably anyone else I know. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Le mardi 26 juillet 2011 12:38:35, vous avez écrit : Sure, why not kill one of the biggest strengths FreeBSD is known for while we're at it... Or most obvious weakness ... The biggest strength was a good kernel, better than Linux, but this was years ago. Two questions: Who will provide the infrastructure to build me all of my packages the day/hour/moment moment I need them and constantly build me the i386, amd64, athlon-tbird optimized, k8-sse3 optimized, -O2 and -O3 optimized, intel-core optimized, and intel-p3 optimized batches for all of my machines? Who will constantly build and maintain my custom set of binary packages and all their dependencies built with the exact specific OPTIONS that I need and without the components that I don't want? This stuff you are mentioning is the precise reason why people have problems with the ports system. By the way, all your optimisations have next to zero impact on performance, and introduce a sizable probability of bugs. And the components you don't want use an infinitesimal part of your hard disk and nothing in your memory. At the end of the day this sort of feature buys no benefit at all and introduces an infinite combinatoric complexity for people wanting to test the ports system. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/11 08:25, Tilman Keskinöz wrote: I shortly went through the list. There are currently 22 PRs filed against portupgrade Of these: 4 are general problems of the ports collection/pkg_tools. (architecture-specific INDEX, Detecting of OPTIONs set, Overriding/removing files changed by the user etc.) 2 are documentation bugs 1 wishlist item 4 contain patches 1 i believed is already fixed, i set to feedback. So this leaves the following, which need someone (a maintainer?) to investigate/write a patch: snip IMHO the situation is not that bad, that we need to DEPRECATE it. Many thanks for going through them, that helps a great deal. I submitted some changes which should help with Ruby 1.9 compatibility, which Stanislav has pushed out to portupgrade-devel. I did some minimal testing with them, but they need more testing. If folks could test the updated portupgrade-devel, with both Ruby 1.8 and Ruby 1.9, I'd appreciate it. That would help us get past the Ruby 1.9 compatibility issue. Thanks, Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOLqQ1AAoJEPXPYrMgexuhI0oH/RtLURpZgsANqGVs9QrQPn5W Haf9wt6sHnWa/1pXL9EoIUmEy8LPvRS9P4kFMwr8zNLtXjjK7ChhSALWApxoLgcE YsJND4ATcQun4mYCMxVECvvRM6egl1u/UmJGO3jOXJz6Dv0Ik5GB8y+3Ssepx5ls QIkEbXU+oXyq2pIsDajWLGBGEAPAOEaVphdLY9Hhvv+tQJDqlZHOkISVa6pqG4zM Kh7upMftP4ce53kC4CPupqXxK9m5OIo4/v+jbNzqmEkySk/CDZvN6qTSWGNVSH5r 20k6ggykmvqS6A7vmaYHxTdwtq1bn+J+YzryIOAyK9+VWVPLxbCMG8URRB8C2GY= =08aD -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
,--- You/Michel (Tue, 26 Jul 2011 11:27:56 +0200) * | while most of people i hear are very unhappy with FreeBSD ports. Nuts. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Tue, Jul 26, 2011 at 01:24:35PM +0200, Michel Talon wrote: Le mardi 26 juillet 2011 12:38:35, vous avez ??crit : Sure, why not kill one of the biggest strengths FreeBSD is known for while we're at it... Or most obvious weakness ... The biggest strength was a good kernel, better than Linux, but this was years ago. Two questions: Who will provide the infrastructure to build me all of my packages the day/hour/moment moment I need them and constantly build me the i386, amd64, athlon-tbird optimized, k8-sse3 optimized, -O2 and -O3 optimized, intel-core optimized, and intel-p3 optimized batches for all of my machines? Who will constantly build and maintain my custom set of binary packages and all their dependencies built with the exact specific OPTIONS that I need and without the components that I don't want? This stuff you are mentioning is the precise reason why people have problems with the ports system. By the way, all your optimisations have next to zero impact on performance, and introduce a sizable probability of bugs. And the components you don't want use an infinitesimal part of your hard disk and nothing in your memory. At the end of the day this sort of feature buys no benefit at all and introduces an infinite combinatoric complexity for people wanting to test the ports system. Ports, manuals and the people. This is why I use FreeBSD. Don't mess with ports. Have no opinion on portupgrade, never used it, portmaster does most of what I need, except for massive updates, e.g. recent icu update. portmaster -r fails for me most of the time (sometimes this is nothing to do with the update tool, but simply because I'm on ia64 and sparc64). I guess one has to accept that manual intervention is required for complex updates. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Hi, On Tue, Jul 26, 2011 at 11:27 AM, Michel Talon ta...@lpthe.jussieu.fr wrote: Jerry wrote: While we are on the subject of port management tools, I still use portmanager when a version bump on a port requires that a massive number of dependencies be rebuild. I have had all too many instances when both portupgrade and portmaster simply bombed out and left me with only a partially updated system, and in many cases, a virtually useless one. Portmanager would simple get the job done right the first time. It might be overkill for one or two port upgrades; however, it works fine on massive projects that seem to bewilder the other two competing contenders. The p5-libwww-5* example in the case of portmaster being a perfect example. This subject of port management tools is a subject i have been much The subject we were discussing was portupgrade; if you want to discuss something else, please start a new thread. Thank you. interested in some years ago, and i must say that the problems which seem to surface now in the general consensus, i had discussed them without any echo at the time. Having a system partially updated hence requiring a lot of work to fix with portupgrade happened to me several times. Horrific slowness of portupgrade was perfectly obvious years ago. I think most of the problems come from errors in the ports themselves so are unfixable through ameliorations in the upgrade tools. I think only a more rigorous management of the ports, i mean something like the separation between unstable, testing, stable in Debian, with rigorous procedures for going from one state to the better one could cure this problem, but at the expense of slowing the development. More importantly, only a procedure centered around *binary* packages could possibly lead to a guaranteed decent state of the ports. Centering things around source code can only lead to confusion, incessant messing by both developers and users with various options etc. which can only destabilize the system. Anyways, to come back to port management tools i don't know how portmanager works, but i think that both portupgrade and portmaster have a fundamental flaw in that they both work locally, upgrading one port after another until the job is finished, which means that the state of the machine is constantly modified, possibly into a broken state, without any possibility for the user to know beforehand that he is headed to failure. A proper tool should do a first pass describing exactly the initial state and the final state so that the end user can choose to upgrade or not. This is what Debian apt-get (or aptitude) does, it describes before any destructive action begins what will be removed, what will be installed. This can only work reliably if you have binary packages, otherwise you can never be sure that a source port will compile. The only *BSD i am aware of that has moved in that direction is OpenBSD. From what i hear, people are happy with the management of ports in OpenBSD, while most of people i hear are very unhappy with FreeBSD ports. I would say that most people your hear isn't a representative subset of all the people who use ports. In my experience anyway. -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Tue, 26 Jul 2011 13:56:14 +0200 Torfinn Ingolfsen articulated: I would say that most people your hear isn't a representative subset of all the people who use ports. In my experience anyway. And that would be based on what, people you interact with which may or may not be a fully represented cross section of the entire FreeBSD community. Michel Talon simple made a statement based on a qualitative analysis of the individuals he had come into contact with or had reason to otherwise receive or access input from. Your statement is of no more value as a definitive assertion than his, so why belittle his remarks? -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Famous last words of Davy Crockett, So what are all those gardeners doing here? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Quoth Torfinn Ingolfsen on Tuesday, 26 July 2011: snip From what i hear, people are happy with the management of ports in OpenBSD, while most of people i hear are very unhappy with FreeBSD ports. I would say that most people your hear isn't a representative subset of all the people who use ports. In my experience anyway. Right. Don't say most people unless you can back it up with a statistically significant sampling. I expect the experiences of FreeBSD users vary much more than most people imagine. Those who have serious difficulties with the ports system may wrongly imagine that all FreeBSD users have the same less than delightful experience. Personally, even though I've run into a few issues with ports, I prefer the current system of building from source. Of course I welcome improvements, but not at the expense of the flexibility we enjoy. -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgpUCVioirxyT.pgp Description: PGP signature
Re: Time to mark portupgrade deprecated?
On Tue, 26 Jul 2011 09:13:20 -0700 Chip Camden wrote: Quoth Torfinn Ingolfsen on Tuesday, 26 July 2011: snip From what i hear, people are happy with the management of ports in OpenBSD, while most of people i hear are very unhappy with FreeBSD ports. I would say that most people your hear isn't a representative subset of all the people who use ports. In my experience anyway. Right. Don't say most people unless you can back it up with a statistically significant sampling. I expect the experiences of FreeBSD users vary much more than most people imagine. It seems more reasonable than the idea that most people using FreeBSD are doing so despite being very unhappy with FreeBSD ports. If that's really true then we should give Beastie nipple-clamps and a ball-gag to better appeal to our key demographic. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On 7/26/2011 3:28 PM, RW wrote: It seems more reasonable than the idea that most people using FreeBSD are doing so despite being very unhappy with FreeBSD ports. If that's really true then we should give Beastie nipple-clamps and a ball-gag to better appeal to our key demographic. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org +1 just because the thought of that is funny as hell! -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) signature.asc Description: OpenPGP digital signature
Re: Time to mark portupgrade deprecated?
On 07/25/2011 04:20 AM, Eitan Adler wrote: At this point noone is maintaining portupgrade any more and a large number of PRs have been filed against it (see http://www.freebsd.org/cgi/query-pr-summary.cgi?text=portupgrade). No one has stepped up to do the work to fix these bugs so it is time to officially drop it. Despite the fact that there are many PRs about it, it still works for most users i guess. I am ok with switching the documentation to portmaster, but i am against marking it DEPRECATED. I have been using portupdate for 10 years and it works for all my usecases. Switching to portmaster means i have to learn new -options and new error messages. Unless there is a killer feature in portmaster i don't see a reason to switch. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Mon, 2011-07-25 at 09:33 +0200, Tilman Keskinöz wrote: I am ok with switching the documentation to portmaster, but i am against marking it DEPRECATED. I have been using portupdate for 10 years and it works for all my usecases. Switching to portmaster means i have to learn new -options and new error messages. Unless there is a killer feature in portmaster i don't see a reason to switch. Basically, this. I'm on the very same boat, so to reiterate it again, from my point of view: 1. Portupgrade may have bugs, sure, but none of them are critical and every one I know about can be easily worked around whenever situation arises. Some of them are so old now that most regular users probably count them as features. 2. I too have been using portupdate for 10 years (hello!) and it works for all my usecases. 3. Switching to portmaster means retraining for a different *mission critical* software, that behaves differently, and that I currently have no need for, because the former one works fine. To point out a specific examply that I see frequently in UPDATING: If you use portmaster: # portmaster -r icu If you use portupgrade: # portupgrade -fr devel/icu Ok, sure, easy task.. Hey..what? In portupgrade, -r builds all my ports recursively and updates those which are out of date, where -f forces it to rebuild every single one along the path. Clear, right? So why is this different for portmaster? Where is my -f[orce] option? Will -r always rebuild everything? Or will it never, as it is with portupgrade without -f used? IF that's the case, how can my scripts recursively rebuild only needed stuff and...damn. Sure, by that time I spent on writing this email, I might have been halfway through portmaster documentation and have my questions answered, but that's obviously not the point - I just don't need, and don't want to. While portupgrade works (and it works), I don't want spending my time on cross-checking every single usecase between portmaster and portupgrade so that my upgrade scripts can safely play with the new popular kid on the block. Unless there is something fundamentally broken with portupgrade (other than a few open PRs) that prevents it from working on a modern FreeBSD system, I don't see a point in deprecation. Especially when portmaster is *NOT* a drop-in replacement. Again, from recent UPDATING: portmaster cannot process the upgrade of www/p5-libwww from version 5 to version 6. To upgrade p5-libwww, use portupgrade instead, or deinstall p5-libwww before reinstalling: If you use portmaster: # pkg_delete -f 'p5-libwww-5*' ; portmaster www/p5-libwww If you use portupgrade, no special treatment is necessary. m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Am 25.07.2011 10:50, schrieb Michal Varga: Sure, by that time I spent on writing this email, I might have been halfway through portmaster documentation and have my questions answered, but that's obviously not the point - I just don't need, and don't want to. You will do once it's the only tool. OK, I wasn't being serious. Seriously the point is that new users should be kept away from a tool that is known to have lots of unfixed bugs. While portupgrade works (and it works), I don't want spending my time on cross-checking every single usecase between portmaster and portupgrade so that my upgrade scripts can safely play with the new popular kid on the block. Unless there is something fundamentally broken with portupgrade (other than a few open PRs) that prevents it from working on a modern FreeBSD system, I don't see a point in deprecation. Especially when portmaster is *NOT* a drop-in replacement. Lack of port quality and maintenance are good reasons for removal. Again, from recent UPDATING: portmaster cannot process the upgrade of www/p5-libwww from version 5 to version 6. To upgrade p5-libwww, use portupgrade instead, or deinstall p5-libwww before reinstalling: If you use portmaster: # pkg_delete -f 'p5-libwww-5*' ; portmaster www/p5-libwww If you use portupgrade, no special treatment is necessary. Doug is aware of the problem, and it isn't a case against portmaster. Frankly I haven't even tried if portupgrade would have been able to handle it. Anyways, there are various upgrades that *neither* of the two tools can handle without manual help of the administrator. This frequently happens if a certain interdependent set of packages (such as GNOME) moves functions between ports, or removes a port. Basically I'd say let's mark portupgrade without EXPIRATION_DATE and with DEPRECATED= and bump PORTREVISION, stating as reason that we need a volunteer to maintain it and else people should use portmaster. If someone picks it up, problem solved. If not, we at least scare new users away and direct them to portmaster. Marking the port DECPRECATED like that gives the maintenance problem a much wider exposure than just repeated discussions on mailing lists that no-one (in relation to the overall user count) reads. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Change is hard. :) I have no objections to someone (or some group) choosing to maintain portupgrade. I've always said that I don't regard portmaster and portupgrade to be in competition. However if no one steps up to maintain it, portupgrade will eventually bitrot and become unusable. So for all of you saying save portupgrade! this is something you seriously need to consider. That said, I was going to avoid responding to this thread altogether however you said some things below that I felt compelled to respond to. On 07/25/2011 01:50, Michal Varga wrote: 3. Switching to portmaster means retraining for a different *mission critical* software, that behaves differently, and that I currently have no need for, because the former one works fine. To point out a specific examply that I see frequently in UPDATING: If you use portmaster: # portmaster -r icu If you use portupgrade: # portupgrade -fr devel/icu Ok, sure, easy task.. Hey..what? In portupgrade, -r builds all my ports recursively and updates those which are out of date, where -f forces it to rebuild every single one along the path. Clear, right? So why is this different for portmaster? Because I never used portupgrade, and I never set out to create a feature-by-feature replacement for it. More pointedly, there are certain things about they way that portupgrade works that I don't like and/or don't agree with; hence my desire to create a new tool. Where is my -f[orce] option? Will -r always rebuild everything? Or will it never, as it is with portupgrade without -f used? IF that's the case, how can my scripts recursively rebuild only needed stuff and...damn. zomg, change is hard. :) Sure, by that time I spent on writing this email, I might have been halfway through portmaster documentation and have my questions answered, but that's obviously not the point - I just don't need, and don't want to. zomg, change is hard. :) While portupgrade works (and it works), I don't want spending my time on cross-checking every single usecase between portmaster and portupgrade so that my upgrade scripts can safely play with the new popular kid on the block. zomg, change is hard. :) Unless there is something fundamentally broken with portupgrade (other than a few open PRs) that prevents it from working on a modern FreeBSD system, I don't see a point in deprecation. I tend to agree with you, actually, but ... Especially when portmaster is *NOT* a drop-in replacement. This is a red herring, as portmaster is never going to be a drop-in replacement for portupgrade. Again, from recent UPDATING: portmaster cannot process the upgrade of www/p5-libwww from version 5 to version 6. To upgrade p5-libwww, use portupgrade instead, or deinstall p5-libwww before reinstalling: If you use portmaster: # pkg_delete -f 'p5-libwww-5*' ; portmaster www/p5-libwww If you use portupgrade, no special treatment is necessary. This issue arose because the maintainer of the port chose a non-standard way of dealing with the issue of one package separating itself into 2 parts, and then chose not to apply the workaround that I suggested for dealing with the problem; which turned out to be an example of an issue that I brought up on the list a little while ago and was told that it didn't need attention because if it happened it was always an error in the port. So just to be clear, if someone wants to maintain portupgrade and/or people want to continue using it, no objection from me. :) Meanwhile, the portmaster man page contains a very detailed treatment of what portmaster does, and how and why it does it. Anyone considering switching is encouraged to install it, and read the man page. Doug (zomg, change is hard.) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Mon, 2011-07-25 at 02:42 -0700, Doug Barton wrote: Change is hard. :) In fact, that's the whole point of the story, ironically or not. I have no objections to someone (or some group) choosing to maintain portupgrade. I've always said that I don't regard portmaster and portupgrade to be in competition. However if no one steps up to maintain it, portupgrade will eventually bitrot and become unusable. So for all of you saying save portupgrade! this is something you seriously need to consider. There is a difference in saving portupgrade and simply cold murdering it from behind just because it's that particular time of the month for a 'change' (cough). Believe or not, as a decade long user, I hated portupgrade from the day one, and learned to hate it even more as the code base bloated and everybody lost a slightest idea how it even holds together to the point where it is today. I can still (though barely) remember times when portupgrade was actually spending 95% cpu time on compilation and rest on fixing / saving / database / dependencies, in contrast to the current 30% compilation time + 70% portupgrade database fractal magic disco that nobody gets anymore. That said, I don't propose (nor volunteer, for the love of god) to maintain portupgrade - I just say - leave it be. As was already said before me - change the handbook/documentation, feel free to wipe all tracks of portupgrade from it, that doesn't matter even slightest to the current portupgrade user base, as we don't read that anyway. But I have machines and scripts that need to be kept up to date and will need to be for years to come, and portupgrade is the current mission critical tool for that. Change is hard, *especially* when there is nothing broken with stuff that already works. Unmaintained portupgrade is not a security threat, it's not a network service, it may have bugs that nobody cares about to fix anymore, but most people [citation needed] don't care about them, they're worked around for years, and a stable bug is almost as good as a feature, isn't it? Again, as you said - portmaster is not a replacement for portupgrade. I have no objections in its promotion to new users as the new, one and only approved way of managing ports, but this in no way cuts it for currently deployed portupgrade setups, where portupgrade works 'just fine' (and can work the same for years to come). Deprecate it, or kill it, and you will only force many current users to keep a local copy, because it's still easier than a change. Is there any win in that? m. -- Michal Varga, Stonehenge (Gmail account) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Mon, Jul 25, 2011 at 12:14:19PM +0200 I heard the voice of Michal Varga, and lo! it spake thus: I have no objections in [portmaster's] promotion to new users as the new, one and only approved way of managing ports, but this in no way cuts it for currently deployed portupgrade setups, where portupgrade works 'just fine' (and can work the same for years to come). +1 For all its troubles (and certainly they are legion), portupgrade gets along with what I try to do. portmaster does 90%, and I fight it tooth and nail on the last 10% (or would, if I didn't just use portmaster instead), because what it's trying to do just doesn't quite match what I'm trying to do. (also, it's really nice having portupgrade around for upgrading portmaster, and portmaster for upgrading portupgrade or ruby*. Even if neither is strictly necessary, it's still very comfortable and comforting ;) I can still (though barely) remember times when portupgrade was actually spending 95% cpu time on compilation and rest on fixing / saving / database / dependencies, in contrast to the current 30% compilation time + 70% portupgrade database fractal magic disco that nobody gets anymore. Just earlier today, I did a perl upgrade on my workstation. That means I upgrade perl, then force-rebuild p5-*. You can darn well bet I used portmaster for that latter. Spending giant piles of time on database fractal magic disco is one thing wrapped around a 10 minute firefox build; wrapped around couple-second perl module builds it's just insane. I'll just fire off a pair of rebuilds... % time portmaster p5-version [...] 2.906u 2.501s 0:07.51 71.9% 706+2679k 0+21io 167pf+0w % time portupgrade -f p5-version [...] 15.555u 8.054s 0:26.55 88.8%299+2510k 0+10io 17pf+0w And really, that's best-case for portupgrade, since p5-version actually has some C files to compile. Most modules are just files to copy, and take less time. Still portupgrade takes more than 3 times as long. 19 seconds of overheard, times 130 p5-*'s, is over 41 minutes on a full rebuild, just to do its hinky-dance. The actual run is out of my backscroll now, but from history: 30 22:17 time nice portmaster p5- 31 22:30 pkgdb -F so it took at most 13 minutes. I know it sat idle a little while before I noticed it was done. Still, portupgrade would be almost an hour, instead of less than a quarter hour. All that said, 95% of my port upgrading happens via portupgrade. Presumably, were there were no other choice, I could twist things around so I'd get by with just portmaster. Maybe someday I'll have to do that due to portupgrade rotting completely out of usability. But I'd be real cranky about being crammed into it while portupgrade still works for me. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Mon, 25 Jul 2011 12:14:19 +0200 Michal Varga articulated: On Mon, 2011-07-25 at 02:42 -0700, Doug Barton wrote: Change is hard. :) In fact, that's the whole point of the story, ironically or not. I have no objections to someone (or some group) choosing to maintain portupgrade. I've always said that I don't regard portmaster and portupgrade to be in competition. However if no one steps up to maintain it, portupgrade will eventually bitrot and become unusable. So for all of you saying save portupgrade! this is something you seriously need to consider. There is a difference in saving portupgrade and simply cold murdering it from behind just because it's that particular time of the month for a 'change' (cough). Believe or not, as a decade long user, I hated portupgrade from the day one, and learned to hate it even more as the code base bloated and everybody lost a slightest idea how it even holds together to the point where it is today. I can still (though barely) remember times when portupgrade was actually spending 95% cpu time on compilation and rest on fixing / saving / database / dependencies, in contrast to the current 30% compilation time + 70% portupgrade database fractal magic disco that nobody gets anymore. That said, I don't propose (nor volunteer, for the love of god) to maintain portupgrade - I just say - leave it be. As was already said before me - change the handbook/documentation, feel free to wipe all tracks of portupgrade from it, that doesn't matter even slightest to the current portupgrade user base, as we don't read that anyway. But I have machines and scripts that need to be kept up to date and will need to be for years to come, and portupgrade is the current mission critical tool for that. Change is hard, *especially* when there is nothing broken with stuff that already works. Unmaintained portupgrade is not a security threat, it's not a network service, it may have bugs that nobody cares about to fix anymore, but most people [citation needed] don't care about them, they're worked around for years, and a stable bug is almost as good as a feature, isn't it? Again, as you said - portmaster is not a replacement for portupgrade. I have no objections in its promotion to new users as the new, one and only approved way of managing ports, but this in no way cuts it for currently deployed portupgrade setups, where portupgrade works 'just fine' (and can work the same for years to come). Deprecate it, or kill it, and you will only force many current users to keep a local copy, because it's still easier than a change. Is there any win in that? I have not seen any verified upside to removing portupgrade from the ports system, so while kill it. While we are on the subject of port management tools, I still use portmanager when a version bump on a port requires that a massive number of dependencies be rebuild. I have had all too many instances when both portupgrade and portmaster simply bombed out and left me with only a partially updated system, and in many cases, a virtually useless one. Portmanager would simple get the job done right the first time. It might be overkill for one or two port upgrades; however, it works fine on massive projects that seem to bewilder the other two competing contenders. The p5-libwww-5* example in the case of portmaster being a perfect example. Just my 2¢. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
My two cents after reading this whole thread: like it or not, portupgrade is currently the official tool (it's in the Handbook and all other docs). So in my view, this is what needs to be done: a) select a new official tool b) create or update said tool so it is working to 95% of all the wishes c) update all the documentation pointing to this new tool, and set a warning (the old tool, portupgrade, is going away in X years) d) wait X years e) remove portupgrade As Doug wrote, change is hard. But there is a difference between change because all other options has run out of time, and planned change. We can make it less hard, at the cost of a longer timeframe. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On 25 July 2011 12:27, Torfinn Ingolfsen tin...@gmail.com wrote: My two cents after reading this whole thread: like it or not, portupgrade is currently the official tool (it's in the Handbook and all other docs). So in my view, this is what needs to be done: a) select a new official tool b) create or update said tool so it is working to 95% of all the wishes c) update all the documentation pointing to this new tool, and set a warning (the old tool, portupgrade, is going away in X years) d) wait X years e) remove portupgrade As Doug wrote, change is hard. But there is a difference between change because all other options has run out of time, and planned change. We can make it less hard, at the cost of a longer timeframe. The usual process of deprecaction is to add a warning in one release, and then remove it in the next. While I appreciate portupgrade isn't part of the base system, I think this process would be appropriate. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On 07/25/2011 04:20 AM, Eitan Adler wrote: At this point noone is maintaining portupgrade any more and a large number of PRs have been filed against it (see http://www.freebsd.org/cgi/query-pr-summary.cgi?text=portupgrade). No one has stepped up to do the work to fix these bugs so it is time to officially drop it. I shortly went through the list. There are currently 22 PRs filed against portupgrade Of these: 4 are general problems of the ports collection/pkg_tools. (architecture-specific INDEX, Detecting of OPTIONs set, Overriding/removing files changed by the user etc.) 2 are documentation bugs 1 wishlist item 4 contain patches 1 i believed is already fixed, i set to feedback. So this leaves the following, which need someone (a maintainer?) to investigate/write a patch: 112818 ruby portsopen non-criti medium current-us ports-mgmt/portupgrade -a fails with database error 127019 ruby portsopen serious medium current-us ports-mgmt/portupgrade does not recognize fail conditions 127889 ruby portsopen non-criti low current-us ports-mgmt/portupgrade detects spurious failures and skips ports unnecessarily 129930 ruby portsopen serious high current-us ports-mgmt/portupgrade - portinstall tries to install dependencies twice 13 ruby portsopen serious medium current-us ports-mgmt/portupgrade-devel: completely removes package on installation error 140008 ruby portsopen non-criti medium current-us ports-mgmt/portupgrade-devel chokes on bsdpan pkgs 147242 ruby portsopen critical medium current-us ports-mgmt/portupgrade incorrectly remove old port when new one fails to compile 151662 ruby portsopen non-criti low current-us ports-mgmt/portupgrade: upgrade of autoconf leaves old version 154210 ruby portsopen serious medium current-us ports-mgmt/portupgrade 2.4.8_1,2: cross-thread violation on rb_gc() IMHO the situation is not that bad, that we need to DEPRECATE it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Mon, 25 Jul 2011, Michal Varga wrote: 3. Switching to portmaster means retraining for a different *mission critical* software, that behaves differently, and that I currently have no need for, because the former one works fine. To point out a specific examply that I see frequently in UPDATING: If you use portmaster: # portmaster -r icu If you use portupgrade: # portupgrade -fr devel/icu Ok, sure, easy task.. Hey..what? In portupgrade, -r builds all my ports recursively and updates those which are out of date, where -f forces it to rebuild every single one along the path. Clear, right? More precisely: portupgrade -r port : upgrade this port, and any outdated ports that depend on it. portupgrade -fr port : upgrade this port, and update or rebuild all ports that depend on it, outdated or not portmaster port : same as portupgrade -r, except it also checks ports on which this one depends, like portupgrade -rR portmaster -r port : same as portupgrade -frR portmaster makes default a lot of the things that portupgrade needs to be told (as above, but also -c and -C). It also parallels some tasks. But the overall killer feature is active maintenance. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On Mon, Jul 25, 2011 at 08:33:24AM -0600, Warren Block wrote: ... portmaster ... But the overall killer feature is active maintenance. Well, that, and the fact that portmaster doesn't depend on bits that it is upgrading. Peace, david (who used to use portupgrade, but switched some time ago) -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpUEUpr6Q7gH.pgp Description: PGP signature
Re: Time to mark portupgrade deprecated?
On Sunday 24 July 2011 18:30:04 Steve Wills wrote: On 07/24/11 22:20, Eitan Adler wrote: At this point noone is maintaining portupgrade any more and a large number of PRs have been filed against it (see http://www.freebsd.org/cgi/query-pr-summary.cgi?text=portupgrade). No one has stepped up to do the work to fix these bugs so it is time to officially drop it. Personally, I agree it's time to drop it if no one is going to do the work to maintain it, which at this point it seems clear is not going to happen. I'd be happy to be proven wrong about that. So the question becomes, how do we go about doing it? First step would be changing the handbook. Most UPDATING entries seem to include both portupgrade and portmaster instructions these days, so that should be covered. The next issue would be warning portupgrade users, perhaps by marking the port DEPRECATED? I'd think a date a little longer than the usual month would be needed before expiring. Why pick portupgrade when a lot of people (including myself) use it? There are probably 100's of ports more worthy of deprecation. Maybe there should be a policy to deprecate all unmaintained ports if nobody steps up. You can always drag it out of the attic if enough people squak and probably find someone to maintain it in the process. Just my .02 Beech -- --- Beech Rintoul - FreeBSD Developer - be...@freebsd.org /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/8.2R/announce.html --- signature.asc Description: This is a digitally signed message part.
Re: Time to mark portupgrade deprecated?
Hi, On Mon, Jul 25, 2011 at 1:40 PM, Chris Rees cr...@freebsd.org wrote: On 25 July 2011 12:27, Torfinn Ingolfsen tin...@gmail.com wrote: My two cents after reading this whole thread: like it or not, portupgrade is currently the official tool (it's in the Handbook and all other docs). So in my view, this is what needs to be done: a) select a new official tool b) create or update said tool so it is working to 95% of all the wishes c) update all the documentation pointing to this new tool, and set a warning (the old tool, portupgrade, is going away in X years) d) wait X years e) remove portupgrade As Doug wrote, change is hard. But there is a difference between change because all other options has run out of time, and planned change. We can make it less hard, at the cost of a longer timeframe. The usual process of deprecaction is to add a warning in one release, and then remove it in the next. While I appreciate portupgrade isn't part of the base system, I think this process would be appropriate. We have lived with portupgrade for ten years or more now. Why the sudden rush to get rid of it? As others have stated, portupgrade is still functional, and there isn't any total failure scenarios imminent that I am aware of. In my view, change is useful in two situations: a) when it brings in new functionality or replaces existing functionality with better functionality b) when it removes dead weight, ie. non-working and non-maintained ports or other programs, thus decreasing the load of the people who have to maintain the code. Since portupgrade is still functional, I would argue that b) doesn't apply. Just my opinion. -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
Why pick portupgrade when a lot of people (including myself) use it? There are probably 100's of ports more worthy of deprecation. Maybe there should be a policy to deprecate all unmaintained ports if nobody steps up. You can always drag it out of the attic if enough people squak and probably find someone to maintain it in the process. Personally, I don't see any reason at all to deprecate it. It works, it's maintained (by ruby@ and me personally) and it's generally useful. If someone feels that there's lack of maintainership here he's always welcome to step in and contribute time/resources. -- ST4096-RIPE___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On 07/25/2011 03:42, Matthew D. Fuller wrote: On Mon, Jul 25, 2011 at 12:14:19PM +0200 I heard the voice of Michal Varga, and lo! it spake thus: I have no objections in [portmaster's] promotion to new users as the new, one and only approved way of managing ports, but this in no way cuts it for currently deployed portupgrade setups, where portupgrade works 'just fine' (and can work the same for years to come). +1 For all its troubles (and certainly they are legion), portupgrade gets along with what I try to do. portmaster does 90%, and I fight it tooth and nail on the last 10% (or would, if I didn't just use portmaster instead), because what it's trying to do just doesn't quite match what I'm trying to do. It would be interesting to hear what 10% of stuff you are fighting with portmaster to accomplish. (also, it's really nice having portupgrade around for upgrading portmaster, and portmaster for upgrading portupgrade or ruby*. Even if neither is strictly necessary, it's still very comfortable and comforting ;) portmaster can update itself just fine, FYI. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Time to mark portupgrade deprecated?
At this point noone is maintaining portupgrade any more and a large number of PRs have been filed against it (see http://www.freebsd.org/cgi/query-pr-summary.cgi?text=portupgrade). No one has stepped up to do the work to fix these bugs so it is time to officially drop it. -- Eitan Adler I ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/24/11 22:20, Eitan Adler wrote: At this point noone is maintaining portupgrade any more and a large number of PRs have been filed against it (see http://www.freebsd.org/cgi/query-pr-summary.cgi?text=portupgrade). No one has stepped up to do the work to fix these bugs so it is time to officially drop it. Personally, I agree it's time to drop it if no one is going to do the work to maintain it, which at this point it seems clear is not going to happen. I'd be happy to be proven wrong about that. So the question becomes, how do we go about doing it? First step would be changing the handbook. Most UPDATING entries seem to include both portupgrade and portmaster instructions these days, so that should be covered. The next issue would be warning portupgrade users, perhaps by marking the port DEPRECATED? I'd think a date a little longer than the usual month would be needed before expiring. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOLNUsAAoJEPXPYrMgexuhUwoH/279L3SKUUaKdSI4eUacIHDC +RDoNvcW06qFiDwEMIPi0olWxQU1O3PnNXVf0X7ackS/k5JElTJUV79Dw7i+4VOW fa5ON9Fi2ggIG93Az+mqDgVGVlFqhCKQWeLypadGWX9Ykx3EitkudC4cXZLxC9Hq pAPC45BoJWVkaAyTwvP3K+jbSCFG+2yY+OIuPIFco+3FP5X5cJcv8x/L43N1tbRa PRvz7MUmDJ+vvQNgwukTdHmfFUH5hZ/Y9E3U79TsIYy/uUhZ8tYZjp9rOn98LOay sfnHY3MoKWxc/fNgrd7T2v4E9kF72rf7uhcdtpz7HHCxHcMzU7sFal+5ZvUQQF0= =TbrA -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On 22:30 Sun 24 Jul , Steve Wills wrote: On 07/24/11 22:20, Eitan Adler wrote: At this point noone is maintaining portupgrade any more and a large number of PRs have been filed against it (see http://www.freebsd.org/cgi/query-pr-summary.cgi?text=portupgrade). No one has stepped up to do the work to fix these bugs so it is time to officially drop it. Personally, I agree it's time to drop it if no one is going to do the work to maintain it, which at this point it seems clear is not going to happen. I'd be happy to be proven wrong about that. So the question becomes, how do we go about doing it? First step would be changing the handbook. Most UPDATING entries seem to include both portupgrade and portmaster instructions these days, so that should be covered. The next issue would be warning portupgrade users, perhaps by marking the port DEPRECATED? I'd think a date a little longer than the usual month would be needed before expiring. I would agree with this for the most part. However, when I recently fubarred my /usr/ports/packages when I accidently terminated in the middle of portmaster operations, I found the easiest way to recover was to use portupgrade (portmaster was complaining about missing packages and deleting/reinstalling/deinstalling/etc failed to fix this). I think its good to have alternate installers for situations like this since they have different strengths and weaknesses. Certainly documentation for portmaster needs to be added and promoted as a ports manager. That being said, I personally have had some vested interest in improving portupgrade and looked over the code when I submitted a patch before knowing no one was fixing it. In my naivete, maybe I could tackle portupgrade... -- milki mi...@rescomp.berkeley.edu ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to mark portupgrade deprecated?
On 7/24/11 10:20 PM, Eitan Adler wrote: At this point noone is maintaining portupgrade any more and a large number of PRs have been filed against it (see http://www.freebsd.org/cgi/query-pr-summary.cgi?text=portupgrade). No one has stepped up to do the work to fix these bugs so it is time to officially drop it. FWIW, it has been working fine for me, and it would have been quite a surprise to find out it was deprecated. (except, of course, that I do follow this mailing list. I'm just saying that someone who isn't following this mailing list might be very surprised if portupgrade were suddenly dropped). Part of me would like to try my hand at fixing whatever the problems are, but I am swamped at work and am very likely to continue to be swapped because the college where I work is very keen on not hiring any more people right now. Maybe I can find some time, but if someone else has the time then certainly they should take the lead. -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
