"... A better implementation would let the port indicate that a port builds on
macOS 10.X or older, or macOS 10.Y or newer. ..."
This sounds like there is a need to allow encoding of version ranges. In which
case I would suggest to solve this problem generically, to allow encoding
version range
Dear MacPorts developers,
I opened a ticket #51645 about 4 weeks ago that affects a library that my
Portfiles rely on. I presume the owners of that package do not have the time
right now to deal with it, so I also posted a patch in the ticket. Is there
anyway to speed up the process for someone
Thanks. That makes things much simpler.
From: Joshua Root [j...@macports.org]
Sent: 09 November 2015 20:02
To: Artur Szostak; MacPorts Development
Subject: Re: Getting proper dependency order using port command
On 2015-11-10 04:35 , Artur Szostak wrote
sforge.org
[macports-dev-boun...@lists.macosforge.org] on behalf of Artur Szostak
[aszos...@partner.eso.org]
Sent: 09 November 2015 18:35
To: macports-dev [macports-dev@lists.macosforge.org]
Subject: Getting proper dependency order using port command
Hi,
I do not see the documentation indicating t
Hi,
I do not see the documentation indicating the options --follow-dependents or
--follow-dependencies for the "port deactivate" command. Therefore I need to
run the deactivate command on one port at a time in the proper order.
How can I get the post-order depth first search of the dependency tr
OK, I got confused because Rainer started off with "Yes this is supported...",
sorry.
I conclude that what I am asking for is not supported.
Thanks.
From: Brandon Allbery [allber...@gmail.com]
Sent: 09 November 2015 18:16
To: Artur Szostak
Cc: Rai
>> Is MacPorts supposed to work correctly if multiple repositories are added to
>> the /opt/local/etc/macports/sources.conf file, each with a different version
>> of the Portfile, but with the same port name?
>> In such a scenario with multiple versions, I notice that things like the
>> followin
Hi,
Is MacPorts supposed to work correctly if multiple repositories are added to
the /opt/local/etc/macports/sources.conf file, each with a different version of
the Portfile, but with the same port name?
In such a scenario with multiple versions, I notice that things like the
following do not a
Hi everyone,
I want to touch on the topic of external repositories for MacPorts again
(related to https://trac.macports.org/ticket/46954).
To summarise:
- If I am not mistaken in my interpretation of the previous email exchange,
there appear to be use cases for allowing easy addition and remova
> Do you already have commit access to the repository?
No, and it is not clear that I should be the one with such access for ESO. This
is something we have to decide here at ESO first.
> If not I can act as a sponsor for those packages, until you get it.
>
> My duty cycle will be more in the r
.
From: dstru...@gmail.com [dstru...@gmail.com] on behalf of David Strubbe
[dstru...@macports.org]
Sent: 01 June 2015 21:06
To: Artur Szostak
Cc: MacPorts Development
Subject: Re: Easy access to external repositories.
Provided the licenses for your software and its
> If you are the maintainer, you should be able to have as much control
> as you wish over the Portfiles and the release cycle. There is no "release
> cycle" for ports really, you can just update them whenever you please.
That will be useful input when we discuss it again at ESO.
One other thing
>>> Did you handle deactivation or did you simply make it impossible.
>>
>> The update of the configuration files is handled during the activation
>> phase and rolled-back during deactivation.
>> So it should all be handled. Deactivating the port should get you back
>> to the same state as if the p
> A general question: what is the purpose of adding a repo for the ESO software,
> as opposed to just committing the individual Portfiles that exist in that
> repo to
> the standard MacPorts repo?
In short, for some of the same reasons that repositories like Fedora EPEL and
other 3rd party repos
>> I tried to write the Portfile so that when one tries to uninstall it, it
>> will undo whatever was done during installation.
>
> So is there 1 Portfile per external repository?
That is what I was thinking, yes.
One could have more than one repository per Portfile if you really want. But I
thin
>> Hmm.. well, that would be nice to try solve the generic problem and allow per
>> package priority. But I do not know of any other production package
>> management
>> system that has implemented such a thing.
>
> Most Linux package managers have priorities associated with repositories.
> We're
> Well, looking at Linux for inspiration doesn't mean we have to do everything
> like them ...
> Linux (at least APT) allows versioned dependencies, and user selection of the
> version to
> be installed for packages that are provided with different versions (even
> through a
> standard GUI like
>> That is why I propose updating the configuration files through a Portfile,
>> such that the
>> average user just has to run the following commands to get access to a 3rd
>> party repository:
>
> You get me wrong. I'm not sure if it's a good idea to make things too easy to
> people who
> don't
> I'm in favor of simplifying the inclusion of 3rd party repositories. The
> Portfile
> proposed in the ticket is hack, but since we don't have a standard mechanism
> to
> do this at the moment, I think we should accept it.
I thought it was a rather clean way to deal with my use case :-)
But su
>> make it much easier for the average user to include an optional 3rd party
>> repository if they so wish.
>
> I'm not sure if 3rd party repositories are something for the average user,
> when average is taken
> from a population where the majority don't know how to edit a configuration
> file
Dear MacPorts developers,
At the moment there does not appear to be any defined mechanism for an end user
to easily select or de-select optional 3rd party repositories. In a ticket I
opened some time ago (https://trac.macports.org/ticket/46954), I proposed a way
to use a Portfile to update the
2015 15:45
To: Artur Szostak; macports-dev
Subject: Re: Programmatically finding dependencies for a Portfile
On 2015-05-28 14:44, Artur Szostak wrote:
> package require macports
> mportinit
> set mport [mportopen "file:///tmp/testport" [list] [list]]
If you want a specific subport,
in [rjvber...@gmail.com]
Sent: 28 May 2015 15:28
To: macports-dev@lists.macosforge.org
Cc: Artur Szostak
Subject: Re: Programmatically finding dependencies for a Portfile
On Thursday May 28 2015 12:44:57 Artur Szostak wrote:
>Given a Portfile, I am trying to programmatically find all
Hi,
Given a Portfile, I am trying to programmatically find all of its direct
dependencies. My approach is to execute an appropriate TcL script in port-tclsh
to produce a listing of such dependencies. I am able to handle Portfiles with
the example script indicated below, but only for Portfiles t
Hi,
Are there any documented tools that can help me to maintain repositories of
MacPorts packages?
i.e. merge repositories, provide a repository diff, produce dependency graphs
etc..
Something on the lines of what the yum-utils package provides for YUM
repositories.
I have not been able to fin
Hi,
Has anyone integrated registration of tab completions for new commands into a
Portfile?
i.e. under Fedora, one would install an appropriate script under
/etc/bash_completion.d/ that makes appropriate calls to "complete", which
registers tab completions for any new commands that your packag
ABI issues.
From: Christopher Jones [jon...@hep.phy.cam.ac.uk]
Sent: 26 February 2015 14:06
To: Artur Szostak
Cc: macports-dev@lists.macosforge.org
Subject: Re: Current best practice to select GCC compiler in Portfile
The best practise is not to do it
Hi,
I couldnt really find this information and I see lots of different approaches
in the Portfiles.
What is the current best practice to select the GCC compiler over the XCode
clang one used by default?
I dont care much about the exact version of the GCC compiler used, but it must
be gcc rather
.
Artur
From: Arno Hautala [a...@alum.wpi.edu]
Sent: 25 February 2015 15:13
To: Artur Szostak
Cc: macports-dev@lists.macosforge.org
Subject: Re: Order of activation/deactivation pre/post phases
On Wed, Feb 25, 2015 at 8:54 AM, Artur Szostak wrote:
>
> Wh
Hi,
Why does a pre-activate phase happen before a deactivation phase when upgrading
from an older port revision to a newer one?
I would have expected the following order:
...
pre-deactivate v1
deactivate v1
post-deactivate v1
...
pre-activate v2
activate v2
post-activate v2
But
>> Our user base wants to use Portfiles and binaries provided in our own
>> repository, but feel intimidated with
>> setting up the repository in the sources.conf, archive_sites.conf and
>> pubkeys.conf files.
>>
>> Alternatively, is it feasible to setup the repository via another Portfile?
>> i
Hi,
Are there any mechanisms for automatic addition of 3rd party MacPorts
repositories?
Our user base wants to use Portfiles and binaries provided in our own
repository, but feel intimidated with setting up the repository in the
sources.conf, archive_sites.conf and pubkeys.conf files.
Alternat
Dear MacPorts developers,
I want to extract various information from Portfiles, such as names, versions,
revisions, dependencies etc. I want to do so without writing another parser. Is
there a reasonably stable API I could use? or, since Portfiles are partial Tcl
scripts, what set of "package r
33 matches
Mail list logo
