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

List:       macports-dev
Subject:    Re: *-devel ports (for llvm and gcc) and dependency declaration "issues"
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2016-05-13 9:13:35
Message-ID: 1539137.5fcsvzohJ6 () patuxbak
[Download RAW message or body]

On Friday May 13 2016 03:27:54 Ryan Schmidt wrote:

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

So you're in favour of providing multiple versions of a product where you stop \
providing updates (bug fixes, security stuff, etc) to a version once it's been \
released? Basically, you'd be OK with providing a series of .0 versions plus the \
current development version (which might be highly unstable)?

Once you find that it's justified to follow a project's development with a -devel \
port, I don't think it's a lot of extra work (on top of the work of keeping ports \
up-to-date that is) when you have both in a single port directory. As long as there's \
development going on on that particular version you may just need to update the \
patchfile list of the release port (with patches from the -devel port) but I don't \
see a reason to remove the -devel port once you stop tracking development. Either you \
leave it just a bit ahead of the latest release port, or you make it a stub port that \
simply depends on the release port.

About those dependency declarations. I wonder if the underlying implementation of a \
port:foo style declaration cannot be evolved to mean "port foo or a drop-in \
replacement".  Let me explain.

I've conceived my KF5 Frameworks meta-port (1 subport per framework) from scratch \
with the idea in mind that I might need to support -devel versions for some \
frameworks. So the KF5 PortGroup contains a number of convenience features. There's a \
procedure that takes a list of short-hand framework names and translates those into \
actual portnames, but the main convenience is a list of variables that contain the \
actual dependency statement for each framework. And those are all of the path:-style, \
using the main binary installed by the port. All of that is hidden from dependent \
ports.

In this case I define those variables myself, and they're available only through the \
PortGroup. 

What if a Portfile could indicate a representative file that it installs via a \
dedicated keyword/command (path:-style, probably better not bin:-style)? It should be \
possible to obtain that information when running portindex, store it in the \
PortIndex, and then expand the `port:foo` expression into a path:-style dependency \
for ports that have used the feature. The only drawback I see is with ports that \
really need to depend on a specific port and no drop-in replacement, but those are \
probably much rarer (and it shouldn't be hard either to add syntax to depend on \
something like exact_port:foo).

R
_______________________________________________
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]