On Sun, 10 Dec 2017 22:33:25 +0100 Stefan Esser <s...@freebsd.org> wrote:
> Am 10.12.17 um 18:47 schrieb Matthieu Volat: > > They do... but only if you commit and push something (even if it's only > > a personnal clone). If you just keep the changes on your computer, there's > > nothing. > The GitHub master version has changes, that are not yet in any release. As someone involved in some projects, I do understand the differences between working trees and releases, this was specifically about helping developpement by being more communicative about it. There's nothing in the commit tree (<https://github.com/freebsd/portmaster/commits/master>) nor the networkd (<https://github.com/freebsd/portmaster/network>) as of now regarding this issue. I don't know for others, but this has led me to invest some time not knowing this was duplicate work. > > This is irrelevant as long as FLAVOR support is missing in portmaster, > since there is no version that fully supports flavors, right now. Please understand I am not asking for a working release, I'm asking for a more transparent developpement process that would allow other people to more easily follow, familiarize themselves with and help in portmaster development... > > > As much as I am defiant of github on certain aspects, I've found in quite > > some occasion the discussion/comment system around pull requests quite > > nice. > > I'm working in FLAVOR support and I have a version that correctly builds > the Python ports, that have been converted. > > But I'm currently trying to understand, where the information that the > ports is to be re-installed, gets lost. Debugging shell scripts is a lot > of work, since you cannot single step through them. Portmaster does call > itself recursively, which further complicates understanding and tracing > the execution. (Besides, portmaster is a main program of 4300+ lines with > functions sprinkled throughout the code. I have a local version, which > breaks this large main program in named subroutines, which makes it much > easier to understand the logic flow, but hides the actual changes when > creating diffs. I have backported the FLAVOR changes to a portmaster > version without those subroutines, to get the minimal functional patch, > but now I'm fighting with the install vs. upgrade distinction being lost.) You can however set the execution trace argument to produce a full log. I was under the impression that when encountering package@flavor, splitting was needed in a few places to match the port directory and then simply add -DFLAVOR=value to the MAKEFLAGS. > > I can send you the current version in private mail (I do not want to spam > the mail-list with a 120k+ shell script). This is exactly why I thought a WIP branch or something of the like would be useful, unless you want to proceed alone without any feedback. But then again, I posted my own (naive) approach at the issue and it did not seems to provoke any feedback, so maybe I was a bit too much hopeful.
pgpxJRx4uqwwf.pgp
Description: OpenPGP digital signature
