Opened 6 years ago

Last modified 6 years ago

#44882 new enhancement

[developer] kdelibs4 4.14/git/master portfile and directory

Reported by: RJVB (René Bertin) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: NicosPavlov, IanWadham, RJVB (René Bertin), mkae (Marko Käning)
Port: kdelibs4

Description

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.

Attachments (3)

files.zip (30.3 KB) - added by RJVB (René Bertin) 6 years ago.
zip archive containing port dir kdelibs4/files
Portfile (8.2 KB) - added by RJVB (René Bertin) 6 years ago.
patchset-RJVB-20141009-against-9ed4f721.diff (51.4 KB) - added by RJVB (René Bertin) 6 years ago.
full patchset of all my current changes to kdelibs 4.14 git/kde4.14.2 (including the Keychain mods), on the brink of tagging for 4.14.3

Download all attachments as: .zip

Change History (15)

Changed 6 years ago by RJVB (René Bertin)

Attachment: files.zip added

zip archive containing port dir kdelibs4/files

comment:1 Changed 6 years ago by RJVB (René Bertin)

Cc: rjvbertin@… added

Cc Me!

comment:2 Changed 6 years ago by RJVB (René Bertin)

The Portfile expects a locally cloned working copy of git://anongit.kde.org/kdelibs in ${prefix}/src/KDE/kdelibs/kdelibs-git

comment:3 in reply to:  2 Changed 6 years ago by larryv (Lawrence Velázquez)

Replying to 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.

comment:4 Changed 6 years ago by larryv (Lawrence Velázquez)

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.

comment:5 Changed 6 years ago by larryv (Lawrence Velázquez)

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 script? That’s our convention, and it’s a lot cleaner.
  • 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.
Last edited 6 years ago by larryv (Lawrence Velázquez) (previous) (diff)

comment:6 in reply to:  5 Changed 6 years ago by danielluke (Daniel J. Luke)

Replying to 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.

comment:7 Changed 6 years ago by ryandesign (Ryan Schmidt)

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.

comment:8 Changed 6 years ago by ryandesign (Ryan Schmidt)

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?

comment:9 Changed 6 years ago by RJVB (René Bertin)

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)?

comment:10 in reply to:  9 ; Changed 6 years ago by larryv (Lawrence Velázquez)

Replying to 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!

comment:11 in reply to:  10 Changed 6 years ago by mkae (Marko Käning)

Replying to larryv@…:

Another benefit of a wiki page

Hi Larry,

actually we do have a 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

comment:12 Changed 6 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

Changed 6 years ago by RJVB (René Bertin)

Attachment: Portfile added

Changed 6 years ago by RJVB (René Bertin)

full patchset of all my current changes to kdelibs 4.14 git/kde4.14.2 (including the Keychain mods), on the brink of tagging for 4.14.3

Note: See TracTickets for help on using tickets.