Releasing code as portgroup instead of in base/

[Daniel J. Luke]

On Oct 13, 2014, at 6:51 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Oct 13, 2014, at 5:31 PM, Daniel J. Luke wrote:
>> On Oct 13, 2014, at 6:19 PM, Ryan Schmidt wrote:
>>> There's no difference in the capabilities of code in a portgroup vs code in a portfile.
>> 
>> portfiles are usually simpler than portgroups (almost by definition).
>> 
>> a portfile that looks like a few key-value pairs is a lot easier to trust/validate than something that sources a bunch of tcl from a portgroup.
> 
> I suppose so. I never considered that there might be users that would actually read a port's / portgroup's / base's code to validate it before installing a port. Do such people actually exist?

I exist, and I do it.

I generally try to at least look over Makefiles (or run make with a dry-run option) before running them with elevated privilege too, but I suspect that most people aren't as paranoid as I am ;-)

The more we can provide options to portfile authors that help them keep to key-value pairs in the portfile, the less likely that they're going to make a mistake too.

> In any case, the point of putting code into a portgroup is to abstract out code common to a set of ports. It's easier to write that code once, correctly, than to copy and paste it into several ports where it has a chance to become out of sync and incorrect. It should also be easier for an interested reader to read and understand that code once in one place than to see it repeated all over the place, and especially to understand any subtle differences that might exist between the copies.

I'm not arguing against that, I'm arguing that it belongs in base/

> We do have versionability in portgroups, it just hasn't been used much so far.

just like we have version-ability in the port API, but we don't use it.

> But in terms of revisions of portgroup, anyone who cares can find out what revision of the portgroup was in use at the time the port was installed. The portfile that was used is in the installed archive, its $Id$ line contains the port's revision, and the corresponding revision of the portgroup that existed at that time can be obtained.

there's no simple way of getting that information from a user who is having a problem.

>> ... but those additional capabilities are probably of marginal utility for most people, so I don't think that they're reasonable immediate design goals - instead there are clearly some areas where we can and should continue to improve.
> 
> Mhm, I think these days the "sudo port selfupdate" step is a stumbling block for many, who expect things to just automatically be up to date.

I haven't used all of the packaging systems that exist - but pretty much everyone I have used requires you to do something to keep things updated.

We expunged kvv's remote port index (and port submission) code a while back, so it doesn't seem like anyone is really interested in working on that (and really, there are plenty of other things to work on that would provide more benefit).

>>> That would for me be the definition of special-case code that doesn't belong in base.
>> 
>> most of base could be construed as special-case code ;-)
> 
> I can't really understand this position at all. In my view, most of base deals with things most ports need.

MacPorts is essentially all special case code to make things work on Mac OS X. My point was more that it's an arbitrary line what is special-case and what isn't, and that's probably not the strongest identifier for where code should live.

If we go strictly empirically, 'most' ports don't need most of the fetch or extract types that base supports - I don't think those should all be moved out into portgroups.

Again, the main point seems to be that it's "too hard" to update base and that's a problem I believe we should fix (make releases easier, possibly do them more often, make base/ easier for people to work with/contribute to).

>>> The other thing I really like about portgroups is that all code related to a particular thing is contained within a single file. When I want to investigate a feature in base, I have to first use grep to figure out what file(s) the code is in, and it's usually spread out all over the place. In the case of imake support, it's only in two files, portconfigure.tcl and portutil.tcl, but that first file is 800 lines long and, like most of base, hard to read, for someone otherwise only accustomed to reading portfiles. Having all the imake- (or whatever-) related code in a single short portgroup file is much easier to understand and change.
>> 
>> it seems like that is a problem with base/ and our dev documentation (or lack of) which it would make sense to fix rather than work around it in that way.
> 
> We don't have any documentation of base, do we? And there are only a few comments in the code. We could try to document it, but that doesn't change the fact that if I'm dealing with providing support for a new build system, I want to do it in a single short file, not try to figure out where in several thousand-line long files it needs to go.

So it's unreasonable to enhance base to allow you to add support for a build system from a single file and/or your lack of desire to work on base isn't indicative of something we should fix?

> I just again see moving a portgroup into base as merely decreasing our ability to develop it effectively without gaining anything for this inconvenience.

because you don't share my concerns/priorities (which is fine) and so you've discounted them as unimportant

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+