[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-dev
Subject:    Re: *-devel ports for llvm and gcc
From:       Ryan Schmidt <ryandesign () macports ! org>
Date:       2016-05-13 8:27:54
Message-ID: 9E8AE86F-EDA2-4912-A117-FA2CBF015AB3 () macports ! org
[Download RAW message or body]


> On May 12, 2016, at 3:51 AM, René J. V. Bertin <rjvbertin@gmail.com> wrote:
> 
> Ryan Schmidt wrote:
> 
> 
> > > is released as a stable version it should be renamed to llvm-3.9. The
> > > ports llvm-3.9 and llvm-3.9-devel are still drop-in replacements.
> > 
> > This makes it much more difficult on developers when the time comes for a port
> > to graduate from development to stable status, as I'm currently doing with
> > gcc6. I don't want to impose that extra work on myself or other developers.
> 
> Why? As you said yourself all that's needed is using a path:-style dependency. 
> That's hardly extra work,

It is extra work for the maintainer to convert all the existing port: dependencies to \
path: dependencies. It is extra work for the maintainer to rename the port from \
-devel to non-devel when it goes stable, and to maintain for one year the -devel stub \
port marked as replaced_by the non-devel port to facilitates upgrades. It is extra \
work for the user to manually uninstall the -devel port after the port has been \
renamed to the non-devel version, since MacPorts currently does not do so \
automatically (https://trac.macports.org/ticket/27552). And all this extra work for \
no benefit.


> and it's probably a good idea to leave that style in 
> place even after the release version of the dependency is produced. It's 
> probably not because llvm 3.8.1 goes stable that there will be no 3.8.1+i that 
> could be tested as a -devel port first.

I don't have any interest in continuing to offer development versions of a port that \
has gone stable, in the case where we offer multiple versions of that port.


> The advantage of using a -devel (sub)port rather than (or in addition to) a 
> category is that other ports can actually depend on the -devel port, if 
> necessary. For instance, clang-3.8-devel (clang-devel-3.8?) would probably have 
> to depend on llvm-3.8-devel (llvm-devel-3.8).

No need for this, if there are no -devel ports for these, as there currently aren't.


> Also, -devel subports can in many cases be subports of the main/release port 
> because they most likely share a lot of code. I do that all the time with my KF5 
> ports.

_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


[prev in list] [next in list] [prev in thread] [next in thread]