On 2016-04-01 17:20, René J.V. Bertin wrote:
> On Friday April 01 2016 15:18:08 Rainer Müller wrote:
>> On 2016-03-31 22:36, René J. V. Bertin wrote:
>
>> Just use a subversion checkout, replace the file and leave it in
>> modified, uncommitted state. You will still get all other changes with
>> 'svn up'.
>
> True. Still, not ideal (and svn is SLOW).
I expect most developers work that way using the ports tree from
subversion as their default entry in sources.conf. I only use Subversion
for my ports tree with lots of local changes...
This is not in any way slower than rsync. With no actual changes, a
simple 'svn up' takes less than 5 seconds for me, the following
portindex also less than 5 seconds. Not much difference if I purge the
disk cache before (MacBookPro10,1 with SM256E SSD).
>>> Rainer Müller wrote:
>>>> The lookup strategy is also the same for mirror/archive sites,
>>>
>>> How many ports need to change those?
>>
>> For ports in external trees? All of them need to define their own
>> mirrors or archive sites.
>
> If they're using mirrors or archive sites that aren't predefined, no? I'm not
> sure about archive sites (where archivefetch downloads from?) but I often see
> my ports attempt to download things from MacPorts mirrors rather than trying
> the master_sites first.
>
>> I am talking about
>> _resources/port1.0/variant_descriptions.conf
>> _resources/port1.0/livecheck/
>>
>> Please just look into the files before making assumptions.
>
> Ok, so those seem to be additional mechanisms to define variants and
> livecheck settings for a whole port tree.
> Can the settings from those files be overridden by a PortGroup?
Yes, they are used in ports like this:
master_sites gnome:sources/${name}/${branch}/
livecheck.type gnome
>> I see this as inconsistency if port groups were looked up differently
>> than the rest of _resources.
>>
>> Apparently not even the current lookup order is documented clear enough,
>> so I would not want to introduce more complexity.
>
> It seems to me that it is above all confusing that _resources are looked up
> differently than the rest of a ports tree
And it would be even more confusing if every single file in _resources
used a different strategy.
It is not even guaranteed that the last entry in sources.conf would be
the [default] entry and your proposal for overriding port groups depends
on that.
For example if you want to keep a ports tree that only contains new and
unsubmitted ports, it is perfectly fine to use this:
# sources.conf
rsync://rsync.macports.org/release/tarballs/ports.tar [default]
file:///Users/raimue/unsubmitted-ports
Now as soon as a port is added to the official tree my unsubmitted
Portfile will no longer be used. Does that mean port groups in
unsubmitted-ports would never be used at all?
Another example, imagine I added a custom ports tree that provides
mirror definitions in _resources/port1.0/fetch/mirror_sites.tcl.
Currently, these are only valid for this ports tree. If this would be
used for all ports, then all your distfile downloads would be broken and
fail...
If we want to have a different lookup order for mirror_sites, it would
actually mean merging the entries or continuing in the next ports tree
if an entry is not found.
On the other hand, _resources/port1.0/fetch/archive_sites.tcl is only
valid for the ports in this tree. It does not make sense to look at
archive_sites.tcl of any other ports tree (maybe we could also look into
the default).
If we want to have a different lookup order for archive_sites, lookup
should stop at this file. Or should we start at the current source and
then go down to other sources?
And so on, the list continues for all the other files in _resources.
I am not saying this cannot be changed, but we need a plan how it should
be handled for each of the files in _resources. Afterwards it could be
implemented, but it looks complicated to me.
Rainer
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
