September 2009 - macports-tickets - lists.macosforge.org

[MacPorts] #18359: Guide has wrong advice about variants
by MacPorts 25 Sep '14

25 Sep '14

#18359: Guide has wrong advice about variants -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: markd@… Type: defect | Status: new Priority: Normal | Milestone: Website & Documentation Component: guide | Version: 1.7.0 Keywords: | Port: -------------------------------------+-------------------------------------- The Guide [http://guide.macports.org/#development.variants.phase says this] of variants: If a variant requires options in addition to those provided by keywords using -append and/or -delete, in other words, any actions that would normally take place within a port installation phase, do not try to do this within the variant declaration. Rather, modify the behavior of any affected phases when the variant is invoked using the variant_isset keyword. {{{ post-destroot { xinstall -m 755 -d ${destroot}${prefix}/etc/ xinstall ${worksrcpath}/examples/foo.conf \ ${destroot}${prefix}/etc/ if {[variant_isset carbon]} { delete ${destroot}${prefix}/bin/emacs delete ${destroot}${prefix}/bin/emacs-${version} } } }}} I do not know why the Guide says this because it is the opposite of what I recommend. It should say something more like: If a variant requires options in addition to those provided by keywords using -append and/or -delete, in other words, any actions that would normally take place within a port installation phase, include these within the variant declaration if possible, so that it is easier to see at a glance what a variant does. If you want to take an action if a variant is *not* set, use the variant_isset keyword. {{{ post-destroot { xinstall -d ${destroot}${prefix}/share/emacs/${version}/leim delete ${destroot}${prefix}/bin/ctags delete ${destroot}${prefix}/share/man/man1/ctags.1 } variant carbon conflicts x11 description {Adds a Mac (Carbon) version of Emacs} { configure.args-delete --without-carbon configure.args-append --with-carbon \ --enable-carbon-app=${applications_dir} post-destroot { delete ${destroot}${prefix}/bin/emacs ${destroot}${prefix}/bin/emacs-${version} } } post-activate { if {![variant_isset carbon]} { ui_msg "Note: You have not selected the +carbon variant" } } }}} -- Ticket URL: <http://trac.macports.org/ticket/18359> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #16969: Cacti: plist to use instead of cron
by MacPorts 25 Sep '14

25 Sep '14

#16969: Cacti: plist to use instead of cron ---------------------------------+------------------------------------------ Reporter: wsiegrist(a)apple.com | Owner: markd(a)macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: Keywords: | Port: cacti ---------------------------------+------------------------------------------ Cacti gives the user instructions for installation involving cron. It would be nice if it also offered a plist to use like: {{{ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.macports.cacti.poll</string> <key>ProgramArguments</key> <array> <string>/opt/local/bin/php</string> <string>/opt/local/share/cacti/poller.php</string> </array> <key>StartInterval</key> <integer>300</integer> <key>UserName</key> <string>_www</string> </dict> </plist> }}} -- Ticket URL: <http://trac.macports.org/ticket/16969> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #16930: more explanation in the guide for startupitems
by MacPorts 25 Sep '14

25 Sep '14

#16930: more explanation in the guide for startupitems ------------------------------------------------+--------------------------- Reporter: dweber(a)macports.org | Owner: markd(a)macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Website & Documentation Component: guide | Version: 1.6.0 Keywords: startupitem daemondo launchd guide | Port: ------------------------------------------------+--------------------------- I found the guide for startupitems is too terse, without adequate background explanation of the tools that implement the process. Please include information on how to get further information, such as: {{{ man launchd man launchctl daemondo --help }}} The latter is helpful, as {{{man daemondo}} doesn't exist (can we create it?). In my case, I found it useful to read through the entire thread that was engaged during the creation of the guide for this section (esp. comments therein from James Berry), ie: Ryan Schmidt, "daemondo defeats purpose of launchd?" at http://lists.macosforge.org/pipermail/macports- dev/2007-September/002669.html If I had time and an understanding of the documentation dev process, I would contribute directly, but it may be easier for the current dev folks to update this section of the guide. I would really like to see a few paragraphs from James' comments adapted into the background for this section of the guide. His comments are succinct and illuminating (esp. in the context of that thread). For example, {{{ daemondo will indeed quit when it detects that the launched process has quit, and thus will "keep alive" the process, since launchd will then restart daemondo. In this way, daemondo acts as a shim or adapter between the scripts supported by the startupitem command, and the single process expected by launchd. The reason that startupitem.executable is preferred is that this gives the best possible chance that daemondo will be able to detect the death of the launched process: since daemondo can launch the process, it can also detect when it quits, stop it, etc. For those cases where startupitem.executable cannot be used, daemondo also supports the startupitem.pidfile commands that allow the process' pidfile to be monitored: daemondo will read the pidfile and watch for the death of that process. So daemondo, and thus launchd, will be aware of the daemon process death (and be able to restart the daemon process) only under two circumstances: (1) startupitem.executable was supplied (thus daemondo starts the process) (2) startupitem.pidfile was supplied (thus daemondo reads the process id) Under all other circumstances, daemondo will not know that the daemon process has died, and will not exit when the process does die, and thus launchd won't restart the process since it doesn't know it died. Put another way, if daemondo can know the process has died, then launchd will know too, but not otherwise. }}} {{{ Note that for simplicity, startupitem.executable is handled by daemondo at present. This has two purposes: - It keeps the startupitem generating code a little simpler. - It allows the potential support for higher value services to be provided by daemondo. In particular, note daemondo's --restart- netchange option, which can be quite useful, but for which there is no current support by the startupitem keys. }}} Also, later in the thread, we have some comments that could be adapted for the guide: {{{ ... I don't see the incompatibility of those statements, but then I again I know what i meant, not necessarily what it means to others ;). The later sentence, btw, is missing a word on the end. It should read: "the pidfile keyword is likely useful only if the executable keyword is not specified." Does that help any? > Looks to me like startupitem.pidfile must be set for a deamon to be > tracked whether it is executable startupitem or not. No, daemondo will track an "executable" in an case (and it doesn't need to know where their pidfile is, generally, since it launches the code and thus knows the pid). In the case of script code (non "executable") daemondo doesn't know the pid, since it doesn't know what the script code did. In this case, it has to rely on reading a pidfile to get the process id, or else simply not know. > And the man page > says startupitem.pidfile is "particularly useful" for > startupitem.executable. Can you explain this? That was either garbage to begin with, or else got messed up in creation of the man page. Off the top of my head I can't see any particular reason to use a pidfile keyword in conjunction with the executable keyword, unless it's to specify that it should delete a pidfile created by the executable, and I'm not sure that even works for that case. Hope that helps. James }}} Best, Darren PS, In the description of the startupitem.pidfile, can we remove the OR operator, ie: {{{ Default: [none] | [${prefix}/var/run/${name}.pid] }}} It's easy to confuse this syntax as either: {{{ Default: [none] }}} OR {{{ Default: [${prefix}/var/run/${name}.pid] }}} However, we do need two arguments: [daemondoAction] [pidFile] -- Ticket URL: <http://trac.macports.org/ticket/16930> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #16900: guide: return values for tcl extensions such as existsuser and adduser
by MacPorts 25 Sep '14

25 Sep '14

#16900: guide: return values for tcl extensions such as existsuser and adduser ---------------------------------+------------------------------------------ Reporter: dweber(a)macports.org | Owner: markd(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: Website & Documentation Component: guide | Version: 1.6.0 Keywords: | Port: ---------------------------------+------------------------------------------ Can we update the guide to indicate the return values for many of the tcl extensions listed here: http://guide.macports.org/#reference.tcl-extensions For example, there is no indication that {{{existsuser}}} returns the UID for a user that exists - what does it return when no user exists - 0? Also, it would be helpful to know whether {{{adduser}}} skips, replaces, or updates specific fields for any user that already exists. Does {{{adduser}}} provide any return values to indicate success or failure (or otherwise - like UID)? Thanks, Darren -- Ticket URL: <http://trac.macports.org/ticket/16900> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #16898: print.css for macports guide
by MacPorts 25 Sep '14

25 Sep '14

#16898: print.css for macports guide ---------------------------------------+------------------------------------ Reporter: dweber(a)macports.org | Owner: markd(a)macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Website & Documentation Component: guide | Version: 1.6.0 Keywords: CSS print.css docbook.css | Port: ---------------------------------------+------------------------------------ I've used the docbook.css to create a print.css adaptation. This provides changes to: a) remove the left navigation bar b) remove the header and footer navigations c) present the "book" in full page width I don't know exactly how to direct this ticket, but here it is! To use it, just add the following link to all the meta headers for any page in the guide: {{{ <link href="print.css" rel="stylesheet" type="text/css" media="print"> }}} -- Ticket URL: <http://trac.macports.org/ticket/16898> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #16355: Document port dir, port file, port edit in the Guide
by MacPorts 25 Sep '14

25 Sep '14

#16355: Document port dir, port file, port edit in the Guide -------------------------------------+-------------------------------------- Reporter: ryandesign(a)macports.org | Owner: markd(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: Website & Documentation Component: guide | Version: Keywords: | -------------------------------------+-------------------------------------- The Guide should explain `port dir`, `port file` and `port edit` The manpage (`man port`) does explain these. A good place for this might be in the [http://guide.macports.org/#development.patches.portfile Portfile Patches section]. There, we tell the user to copy the Portfile and then edit it, but we never tell the user where the Portfile is so that they can accomplish this. -- Ticket URL: <http://trac.macports.org/ticket/16355> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #15819: Add a pointer to 7.2 in 4.2 and/or 4.6
by MacPorts 25 Sep '14

25 Sep '14

#15819: Add a pointer to 7.2 in 4.2 and/or 4.6 --------------------------------+------------------------------------------- Reporter: ocroquette(a)free.fr | Owner: markd(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: Component: guide | Version: 1.6.0 Keywords: | --------------------------------+------------------------------------------- Right now the new port maintainer is not really guided from one step to the other to create a new port, especially the jump to the last one (chapter 7). For people who wants to submit a new portfile from scratch, it would be useful to have a link from 4.2 and/or 4.6. Or may be even a quick howto referencing 4. and 7. -- Ticket URL: <http://trac.macports.org/ticket/15819> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #15818: Describe when to run "portindex"
by MacPorts 25 Sep '14

25 Sep '14

#15818: Describe when to run "portindex" --------------------------------+------------------------------------------- Reporter: ocroquette(a)free.fr | Owner: markd(a)macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Component: guide | Version: 1.6.0 Keywords: | --------------------------------+------------------------------------------- Document in 4.2 and 4.6 for which changes to the Portfile re-running portindex is necessary. -- Ticket URL: <http://trac.macports.org/ticket/15818> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #15784: MacPorts Guide, PortGroup perl5: need to document perl5.use_module_build
by MacPorts 25 Sep '14

25 Sep '14

#15784: MacPorts Guide, PortGroup perl5: need to document perl5.use_module_build ----------------------------------------------+----------------------------- Reporter: stolen-from-macports-trac(a)l2g.to | Owner: jmpp(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: Website & Documentation Component: website | Version: 1.6.0 Keywords: | ----------------------------------------------+----------------------------- http://guide.macports.org/#reference.portgroup.perl The documentation ought to mention the perl5.use_module_build keyword, specific to the perl5 PortGroup. This is used for Perl modules that require Module::Build. -- Ticket URL: <http://trac.macports.org/ticket/15784> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #15625: Guide doesn't explain variants very well
by MacPorts 25 Sep '14

25 Sep '14

#15625: Guide doesn't explain variants very well -------------------------------------+-------------------------------------- Reporter: myrrhlin(a)gmail.com | Owner: markd(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: Component: guide | Version: 1.6.0 Keywords: doc variants guide wiki | -------------------------------------+-------------------------------------- There are some obvious questions about variants which are not answered in the guide (and also not in the FAQ). I only began to figure out the answers by trying things and finding out what worked and what didn't. The guide should be expanded to answer these questions. * Can multiple variant options be selected at install time? (yes) * Do variant options sometimes conflict, and how would I know? (??) * Can two variants be installed at the same time? (yes, but only one can be active at a given time. use port deactivate on the first variant, then install the second) * Can an existing variant be modified to add or remove variant options? (no) * What if I need to add a new option to a variant (or remove one)? (uninstall it, then reinstall with the desired options) * Is the 'universal' variant considered to be exclusive of all other options? That is, if there is an option that enables liba52 support, am I to assume the universal install doesn't have this support? (??) * The documentation mentions turning off 'default' variant options with the minus sign syntax -- how do I find out which are the default ones, if any (other than reading the portfile)? (??) I might add that the short descriptions of the variants are quite unclear to me, and insufficient. They're the sort of description which are adequate if you already know what the options mean. If you don't, it doesn't help much in making wise choices. I hope you consider support for greater documentation of these choices in the portfiles or elsewhere, more than a fraction of a line. The wiki would also be a great place for further documentation of this kind, if it was expanded to include pages for every port with variants. Please make it easier somehow for the documentation of variants to be expanded. Here's an example. Whats the difference between darwin7, darwin8, macosx options as opposed to universal? I know 10.4 is darwin 8 (you should explain that too), but just when do I need to specify that? Anytime I see it given as a variant? Are darwin7 and darwin8 exclusive? Are darwin8 and macosx exclusive? How would I know? Another example. I see that ffmpeg includes native support for vorbis and xvid, but there are variant options to use external libraries instead. What are the advantages to each choice? Which provides greater speed/flexibility/etc? -- Ticket URL: <http://trac.macports.org/ticket/15625> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3