[MacPorts] #44882: [developer] kdelibs4 4.14/git/master portfile and directory
#44882: [developer] kdelibs4 4.14/git/master portfile and directory -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch | Port: kdelibs4 -------------------------+-------------------------------- As announced on the kde-mac ML, I have prepared a Portfile and directory to install the git/master (4.14) kdelibs4 branch. This port installs fine with the remaining KDE ports left at their current versions (KDE 4.12.5). However, I see this mostly as a convenience port for developers working on KDE/MacPorts and interested to work directly on a branch that is still open for bug reports and fixes. -- Ticket URL: <https://trac.macports.org/ticket/44882> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by rjvbertin@…): The Portfile expects a locally cloned working copy of git://anongit.kde.org/kdelibs in ${prefix}/src/KDE/kdelibs/kdelibs-git -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by larryv@…): Replying to [comment:2 rjvbertin@…]:
The Portfile expects a locally cloned working copy of git://anongit.kde.org/kdelibs in ${prefix}/src/KDE/kdelibs/kdelibs-git
This is an extremely odd requirement for a port in our public ports tree. I don’t particularly like it. -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by larryv@…): Why the `+no_root` variant? Why not just check `${install.user}` and change the port’s behavior as appropriate? Plus, we don’t do “no_FOO” variants anymore. -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by larryv@…): Other comments: - It’s not acceptable for `revision` to be a date. The point of `revision` is to represent the versioning of the Portfile, not of the packaged software. If you want to incorporate the date into the version, you’d do something like {{{ version 4.14.0-20140902 }}} - `master_sites` is not used if `fetch.type` is “git”. - You use this idiom frequently: {{{ variant FOO {} if {[variant_isset FOO]} { do some stuff } }}} Why not just put the stuff inside the variant block? That’s our convention. - There’s no reason to check whether `startupitem.install` is available. The released version of MacPorts has it, so all Portfiles should just assume it’s there. -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by dluke@…): Replying to [comment:5 larryv@…]:
Other comments: - It’s not acceptable for `revision` to be a date. The point of `revision` is to represent the versioning of the Portfile, not of the packaged software. If you want to incorporate the date into the version, you’d do something like
Is this policy? I don't think it's necessarily a bad idea to use/abuse revision like this. -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by ryandesign@…): `revision` is an unsigned integer. It should start at 0 and increase by 1 for each time the port should be rebuilt but its version does not change. -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by ryandesign@…): This is a portfile for kdelibs4, but of course we already have a kdelibs4 port. So... what are you thinking we should do with this new portfile? -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by rjvbertin@…): First off, and I'm sorry if that wasn't clear, this is NOT a submission for a new port, or for an upgrade of an existing port to be included in an upcoming release. I've uploaded it hoping to help others working on KDE on OS X, allowing them to grab the port directory from here, install it in their local port registry and then use it. That's why I labelled it as an enhancements instead of a If there's a more appropriate place to put this kind of thing online I'm happy to use that, but in the meantime I thought there's little harm putting it here. This "special status" is why I took the liberty to deviate from conventions/dogma. - I kept a number of settings that aren't used for git Portfiles; outcommented others : I didn't want to change the portfile too much, allowing for easy-enough reverting to a stable release version. - The revision number is indeed the date of the commit expected in the local git clone. The result is that the copy of the clone that MacPorts makes has an invariant name. I find that makes for an easier workflow if you're making modifications in the local git clone and then copy them into MacPort's copy before rebuilding. - That local git clone. Remember that this is a port aimed at other developers. Indeed I could have put a reference to the remote repo there, but one way or another those other developers are probably going to want change it for a reference to their own local git clone ... so I put in a reference to a reasonable location. - no_root variant: not mine. It must have been in the original kdelibs4 portfile. I did add a +nostrip variant, which I *could* have made the default given this is a developers portfile... - startupitem.install: idem, not mine. - variant definition syntax: again, it's the syntax I copied from the portfiles I work(ed) off. I agree it's not a very clean syntax, but wasn't even aware there's a cleaner way to do things. (Or, IIRC, I tried at some point and the variant wasn't picked up so I went back to the current redundant way.) So to answer Ryan's question: I'm not particularly expecting you (plural) to decide anything. I think trac is a place with resources for MacPorts developers, and this is just that. BTW, I presume attachments can be added/replaced by others too, or is that something only the submitter can do (just like permissions for changing things like keywords are reserved to ... admins)? -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by larryv@…): Replying to [comment:9 rjvbertin@…]:
First off, and I'm sorry if that wasn't clear, this is NOT a submission for a new port, or for an upgrade of an existing port to be included in an upcoming release. I've uploaded it hoping to help others working on KDE on OS X, allowing them to grab the port directory from here, install it in their local port registry and then use it. That's why I labelled it as an enhancements instead of a If there's a more appropriate place to put this kind of thing online I'm happy to use that, but in the meantime I thought there's little harm putting it here.
Ah. Perhaps a wiki page linked from [[KDE]] might work better? It would also be editable :)
- The revision number is indeed the date of the commit expected in the local git clone. The result is that the copy of the clone that MacPorts makes has an invariant name. I find that makes for an easier workflow if you're making modifications in the local git clone and then copy them into MacPort's copy before rebuilding.
The problem there (and this is why we don’t abuse `revision` like this) is that we want to divorce upstream versions from Portfile versions, so to speak. If you use `revision` as part of your upstream version, there’s no way to distinguish whether a revbump is due to a Portfile adjustment or an upstream change, short of looking at the Subversion log. So any version information that pertains to the software being packaged should be entirely contained in `version`.
- That local git clone. Remember that this is a port aimed at other developers. Indeed I could have put a reference to the remote repo there, but one way or another those other developers are probably going to want change it for a reference to their own local git clone ... so I put in a reference to a reasonable location.
Another benefit of a wiki page would be that you could clearly spell out these special requirements and procedures. Perhaps even provide step-by- step instructions for getting set up. Or anything you’d like! -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
#44882: [developer] kdelibs4 4.14/git/master portfile and directory --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: kdelibs4 | --------------------------+-------------------------------- Comment (by mk@…): Replying to [comment:10 larryv@…]:
Another benefit of a wiki page
Hi Larry, actually we do have a [wiki:KDEProblems wiki page especially dedicated for KDE development] and I try my best to keep it as up-to-date as possible. As nicos is releasing KDE 4.13.3 ports ATM we'll soon have stuff for 4.14 listed there. As you'll see there we've got quite a bit of various kinds of instructions there. Greets, Marko -- Ticket URL: <https://trac.macports.org/ticket/44882#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts