Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On Feb 11 22:25, Lev Serebryakov wrote: On 07.02.2016 17:28, John Marino wrote: ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? -- // Lev Serebryakov Remember that before portmaster we had cvsup which was written in Modula-3 and portupgrade which is written in Ruby. Whilst it is nice that portmaster is just a simple shell script with no dependancies that's a relatively new thing. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07.02.2016 17:28, John Marino wrote: > ports-mgmt/synth. I would love to hear what signficant thing > portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJWvOAdXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePG38P/2y6BiUF0XgBmPPq0KE+Vfui fFeszBcYZ9AfPD92jKXMbvMsMoY93WZRQB69TmQ4c7zXZLQvSvoT9CSjMMzdzOfq UHVuiEpsCz2q4knwij5G9W5IGomxgT9tc/g26tameuZVu8ududFLNCcofX8zS6pb pFLoUTKkALmAJOwyxtMOwtrSGeZXrbq1C6FpXFOXuO7aMcmLA5qDicqdZSNhBDWG 27jjECGM0RyPMChA6OMjYqvzyP6Y3TjAfnxy9PI8S8jXY/oXKVebdRpl27VqRaYw A5gelEb45BGaxF77b35ZTd8gObesoW9i30KmoEEmDTyAwaRjfce8g7WRmvJpNQEy BcYaJYDDtT/oSbLh/XqMNPCmRbNlSaQId4QJmlzpPlbwVHlBtw3EKZS6PVRQG30U Nn40YEiLqhy6uL33VENmsQlRJxnlhOICP24mQUfiWoIYjww91QEL3CCIQilL79rN FarIAv+SVNld+2AnT+Q1WnqrYX5DNSyhIbjm7VpB1GGBnSGXCjeHvkYGl4JAl9H+ 4xm3otpZLU6SsdePSgqJ8fSd0iKygHNixrzYYv+o6DuDEC2JU//G7994r5xM3KXO +CTXd/KlruyK4eIJ32gTcU+nQ21hzlMfgviTLgEKOJplfVWDZ92aFpJaXOnKj4OP LuFstIC8L6cEjxh8Fm5m =JBt1 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On Sun, Feb 07, 2016 at 11:03:04AM +1100, Greg 'groggy' Lehey wrote: > I'm bringing this to the attention of the ports community to try to > come up with a consensus about how to handle existing documentation > for ageing packages, in this case portmaster. > > This bug report suggests removing the documentation for portmaster > because it is out of date and no longer maintained. > > But it's still in the ports tree, and people still use it. The > current wording (4.5.3.1) claims it is the recommended tool, which is > clearly out of date. marino@ (the submitter) writes: > > On Friday, 5 February 2016 at 7:33:33 +, bugzilla-nore...@freebsd.org > wrote: > > > > You have a tool presented as "official" that hasn't had it's > > original maintainer in 4 years and was only kept on life support up > > until 9 months ago. > > Agreed, the "official" (the term used is "recommended") status is > gone. But that's a reason to fix the documentation, not remove it. > As I see it, we have three choices, in increasing order of > desirability: > > 1. Remove all mention of portmaster. That's what this PR recommends. > 2. Do nothing. > 3. Update the documentation to indicate the current status, > recommending alternatives if possible. > > The real issue here is that we shouldn't remove documentation for > software that is still available. In addition, wblock@ writes: > > On Friday, 5 February 2016 at 14:48:07 +, bugzilla-nore...@freebsd.org > wrote: > > > > At present, portmaster still has no direct competition... > > More generally, the way I see it is simple: we should try to keep the > documentation as up-to-date as possible. This means that we don't > remove documentation for existing packages. It also means that we may > need to change the content of the documentation if the status (not > necessarily the content) of the package changes. > > One of the arguments for removing it from the handbook is that it has > a man page. That has some merit, but it doesn't help the people who > have used portmaster and now don't know what to do. Even if portmgr > is deprecated, the documentation should suggest a replacement. > > Can portmgr@ come up with a clear, easy-to-understand policy? > In my opinion there is no reason to remove the mention of portmaster in the handbook as long as it is not "official" and "recommended" but just listed as a possible tools. There are plenty of documentation on the handbook to explain how to use $third party tools. portmaster has some design flaws and clearly synth has a way better and safer one. But that does not mean portmaster is ready to go away as there are plenty of users using it still and for some cases, no alternative is available. For instance, as far as I know synth is not available on non i386/amd64 architectures which is imho the major issue for being a candidate for a replacement of portmaster. As much as I don't like the way portmaster (and portupgrade) are designed: aka unsafe building, there are still IMHO no alternative by the fact that an alternative should cover all our supported architectures. For i386/amd64 users yes synth is a viable alternative and a way safer one. Also note that synth is still very young and before pushing anything that would kill others, it would be good to be more patient and and see how the tool behave/is adopted/is maintained over the time. Regarding portmaster, I think it would be time to deprecate it and remove it from the ports tree/documentation the day when it prevents us from adding an important feature into the ports tree, which may or may not happen soon. Out of my mind such features could be: - subpackages - flavours/variant Note that the above would require changes in all the port management tools. Also note that as far as I know noone is working on the first (subpackages) and someone picked up the work on flavours/variants based on where I stopped but I don't think it will land in the ports tree any time soon. (also note I'm not working on those feature anymore for now, because of ENOTIME :() BTW: just a clarification on the dependency front: - at runtime synth depends on only 1 port: ncurses - at bulidtime it depends on 2 ports: ada (gcc-aux)/ncurses (gcc-aux itself my drag other build dependency. Best regards, Bapt signature.asc Description: PGP signature
Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On 2016-Feb-07 15:28:56 +0100, John Marino wrote: >Please do an honest "fly-off" between ports-mgmt/portmaster and >ports-mgmt/synth. I would love to hear what signficant thing portmaster >can do that Synth can't. (honestly) Off the top of my head: Has no other ports dependencies: portmaster - tick synth - bzzt fail. As far as I'm concerned that makes it an immediate non-starter. I have been bitten too many times by portupgrade updating one of its myriad dependencies, then exploding and requiring manual repairs. -- Peter Jeremy signature.asc Description: PGP signature
Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On Sun, 7 Feb 2016, John Marino wrote: I am not portmgr, but do use portmaster for updating ports on systems running STABLE or HEAD. I still see no tool which provides the features of portmaster. I also realize that this is far from a universal opinion. Please do an honest "fly-off" between ports-mgmt/portmaster and ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) portmaster's one big feature has always been that it has no dependencies. That was and is important. One of the motivators for portmaster was portupgrade's Ruby and ruby-bdb dependencies, which often broke upgrades. I have not tried Synth due to the Ada dependency, and so do not know if it has other portmaster-like abilities, like installing or upgrading a port from the command line with just an origin (portmaster devel/git) or whether it can build or upgrade a port or group of interdependent ports on the host system rather than in a chroot or jail. That's not the point. The point is a sanctioned "official" tool is not maintained and my position is that is UNACCEPTABLE. To be in the handbook it must be a hard requirement to be *ADEQUATELY* maintained. I do not believe that requirement is being met today. I have committed a change to the Handbook that rewords the portmaster entry. It removes "recommended", replacing it with "smallest", and clarifies and simplifies some other text. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
> I am not portmgr, but do use portmaster for updating ports on systems > running STABLE or HEAD. I still see no tool which provides the features of > portmaster. I also realize that this is far from a universal opinion. Please do an honest "fly-off" between ports-mgmt/portmaster and ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) disclaimer: I have obvious bias, I wrote Synth and one *specific* goal to was address claims like yours above, meaning that I wanted to remove that excuse as a valid reason to leave portmaster in the status quo. > I believe that the issue of it having a man page is completely irrelevant. That was to counter the claim that portmaster "needs" documentation. The point is that it *has* documentation. > The handbook covers pkg, portsnap, and freebsd-update, all of which have > very comprehensive man pages and are covered in the handbook because man > pages and the handbook serve very different purposes. Every port should > have a man page, though I understand why many lack one and ports that > support the basic management of a system belong in the handbook. When > multiple and popular tools are available for the same job, it would be good > to summarize any different capabilities that might make one preferred over > another. That's not the point. The point is a sanctioned "official" tool is not maintained and my position is that is UNACCEPTABLE. To be in the handbook it must be a hard requirement to be *ADEQUATELY* maintained. I do not believe that requirement is being met today. John ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On Sat, Feb 6, 2016 at 4:03 PM, Greg 'groggy' Lehey wrote: > I'm bringing this to the attention of the ports community to try to > come up with a consensus about how to handle existing documentation > for ageing packages, in this case portmaster. > > This bug report suggests removing the documentation for portmaster > because it is out of date and no longer maintained. > > But it's still in the ports tree, and people still use it. The > current wording (4.5.3.1) claims it is the recommended tool, which is > clearly out of date. marino@ (the submitter) writes: > > On Friday, 5 February 2016 at 7:33:33 +, > bugzilla-nore...@freebsd.org wrote: > > > > You have a tool presented as "official" that hasn't had it's > > original maintainer in 4 years and was only kept on life support up > > until 9 months ago. > > Agreed, the "official" (the term used is "recommended") status is > gone. But that's a reason to fix the documentation, not remove it. > As I see it, we have three choices, in increasing order of > desirability: > > 1. Remove all mention of portmaster. That's what this PR recommends. > 2. Do nothing. > 3. Update the documentation to indicate the current status, > recommending alternatives if possible. > > The real issue here is that we shouldn't remove documentation for > software that is still available. In addition, wblock@ writes: > > On Friday, 5 February 2016 at 14:48:07 +, > bugzilla-nore...@freebsd.org wrote: > > > > At present, portmaster still has no direct competition... > > More generally, the way I see it is simple: we should try to keep the > documentation as up-to-date as possible. This means that we don't > remove documentation for existing packages. It also means that we may > need to change the content of the documentation if the status (not > necessarily the content) of the package changes. > > One of the arguments for removing it from the handbook is that it has > a man page. That has some merit, but it doesn't help the people who > have used portmaster and now don't know what to do. Even if portmgr > is deprecated, the documentation should suggest a replacement. > > Can portmgr@ come up with a clear, easy-to-understand policy? > > Greg > I am not portmgr, but do use portmaster for updating ports on systems running STABLE or HEAD. I still see no tool which provides the features of portmaster. I also realize that this is far from a universal opinion. I believe that the issue of it having a man page is completely irrelevant. The handbook covers pkg, portsnap, and freebsd-update, all of which have very comprehensive man pages and are covered in the handbook because man pages and the handbook serve very different purposes. Every port should have a man page, though I understand why many lack one and ports that support the basic management of a system belong in the handbook. When multiple and popular tools are available for the same job, it would be good to summarize any different capabilities that might make one preferred over another. Of course, someone has to write it. :-( -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
I'm bringing this to the attention of the ports community to try to come up with a consensus about how to handle existing documentation for ageing packages, in this case portmaster. This bug report suggests removing the documentation for portmaster because it is out of date and no longer maintained. But it's still in the ports tree, and people still use it. The current wording (4.5.3.1) claims it is the recommended tool, which is clearly out of date. marino@ (the submitter) writes: On Friday, 5 February 2016 at 7:33:33 +, bugzilla-nore...@freebsd.org wrote: > > You have a tool presented as "official" that hasn't had it's > original maintainer in 4 years and was only kept on life support up > until 9 months ago. Agreed, the "official" (the term used is "recommended") status is gone. But that's a reason to fix the documentation, not remove it. As I see it, we have three choices, in increasing order of desirability: 1. Remove all mention of portmaster. That's what this PR recommends. 2. Do nothing. 3. Update the documentation to indicate the current status, recommending alternatives if possible. The real issue here is that we shouldn't remove documentation for software that is still available. In addition, wblock@ writes: On Friday, 5 February 2016 at 14:48:07 +, bugzilla-nore...@freebsd.org wrote: > > At present, portmaster still has no direct competition... More generally, the way I see it is simple: we should try to keep the documentation as up-to-date as possible. This means that we don't remove documentation for existing packages. It also means that we may need to change the content of the documentation if the status (not necessarily the content) of the package changes. One of the arguments for removing it from the handbook is that it has a man page. That has some merit, but it doesn't help the people who have used portmaster and now don't know what to do. Even if portmgr is deprecated, the documentation should suggest a replacement. Can portmgr@ come up with a clear, easy-to-understand policy? Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua signature.asc Description: PGP signature
