Opened 17 years ago

Closed 16 years ago

#14553 closed enhancement (fixed)

RFE: Move portgroups into the ports tree

Reported by: raimue (Rainer Müller) Owned by: raimue (Rainer Müller)
Priority: Normal Milestone: MacPorts 1.7.0
Component: ports Version: 1.6.0
Keywords: portgroups Cc: nox@…, ryandesign (Ryan Carsten Schmidt), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), febeling@…
Port:

Description

Instead of keeping the portgroups in our base, they should be distributed with the ports tree itself. This makes updating them much easier. Also, they are more related to the ports tree than to base.

Change History (20)

comment:1 Changed 17 years ago by raimue (Rainer Müller)

Status: newassigned

comment:2 Changed 17 years ago by raimue (Rainer Müller)

As also said on #14482, I am in favor of adding an .resources directory to the source tree to store the port groups and other metadata related directly to the ports tree.

comment:3 Changed 16 years ago by jmroot (Joshua Root)

Everything under ${prefix}/share/macports/resources/ should really be synced along with the ports tree.

comment:4 Changed 16 years ago by nox@…

Cc: nox@… added

Cc Me!

comment:5 Changed 16 years ago by nox@…

Why ".resources"? Why an hidden directory?

comment:6 Changed 16 years ago by jmroot (Joshua Root)

I agree that .resources may not be the best name. But that's a minor detail.

comment:7 Changed 16 years ago by raimue (Rainer Müller)

I chose a hidden directory to have a simply way to avoid portindex recursing into it. Also, this clearly distinguishes between port categories and special directories. Do you think a hidden directory will cause problems? rsync and svn can handle that just fine.

comment:8 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

If it's not a port directory (and the resources directory isn't), then it shouldn't be in the dports directory. :) It should be at the same level as the dports directory IMHO.

comment:9 Changed 16 years ago by raimue (Rainer Müller)

In my opinion the port groups are part of the inidividual ports tree they are made for. They are necessary to build the ports in this tree and should be distributed with this tree. I already implemented a way to find the resources/config/metadata (whatever we want to call it) directory for a ports tree on the variant-descs-14482 branch.

This way it would also be possible to use port groups in external third-party trees. For example, you can also add an older version of a port using an older version of a port group into their own tree, without any conflicts to the official tree.

My intention is that they should be synced from the same URL. A possible solution would be to create dports/ports/ and dports/resources/ to separate them both.

Just as a side note, originally I thought about distributing port groups as ports, but that creates a chicken and egg problem. A Portfile can't add a dependency on another port providing the group, because the Portfile cannot be parsed successfully without the group. So the only way to distribute it within the tree is to designate a special directory there.

comment:10 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: mcalhoun@… added

Cc Me!

comment:11 in reply to:  9 Changed 16 years ago by jmroot (Joshua Root)

I'd prefer something like _resources so that it's visible.

Replying to raimue@…:

In my opinion the port groups are part of the inidividual ports tree they are made for. They are necessary to build the ports in this tree and should be distributed with this tree. I already implemented a way to find the resources/config/metadata (whatever we want to call it) directory for a ports tree on the variant-descs-14482 branch.

This way it would also be possible to use port groups in external third-party trees. For example, you can also add an older version of a port using an older version of a port group into their own tree, without any conflicts to the official tree.

OK, but what happens in the case of multiple sources where not all of them have portgroup/mirror_sites/etc files because they expect them to be supplied by base? Is there a way of doing The Right Thing with fallbacks and not getting e.g. some modified version of a portgroup from one source when you really want the standard one from another source?

comment:12 Changed 16 years ago by febeling@…

Cc: febeling@… added

Cc Me!

comment:13 Changed 16 years ago by raimue (Rainer Müller)

My idea on this was to add more flags to sources.conf. Currently the only used flag is nosync to prevent syncing with 'port sync'. It is used like this:

rsync://rsync.macports.org/release/ports/ [nosync]

We could add new flags which describe inheritance of other port trees using name keys: [name=bar,inherit=foo]. (Side note: the name could also be used in port info and similar to indicate the source).

Or just add a flag named "default" which indicates that this will always be used as lookup if something is not present in another ports tree.

comment:14 Changed 16 years ago by blb@…

I vote for default_group or something to that effect, nice and simple and should be easier to implement and test; creating a virtual tree here from flags could be messy...This way the default tree from rsync.macports.org would always have that set so local trees can check their local path for a given group, and if not found, have a useful fallback.

comment:15 Changed 16 years ago by raimue (Rainer Müller)

Milestone: MacPorts base enhancementsMacPorts 1.7.0

comment:16 Changed 16 years ago by blb@…

resources/port1.0/install/prefix.mtree appears to contain install-specific information:

/set type=dir uname=blb gname=blb mode=0755

should this file be moved elsewhere?

comment:17 Changed 16 years ago by jmroot (Joshua Root)

${datadir}/macports seems like the place for prefix.mtree to live.

comment:18 in reply to:  17 Changed 16 years ago by blb@…

Replying to jmr@…:

${datadir}/macports seems like the place for prefix.mtree to live.

That's what I thought, hence moving in r41463; though note that the Makefile did and does use ${INSTALLDIR}/share instead of ${datadir}, should that be updated?

comment:19 Changed 16 years ago by jmroot (Joshua Root)

Probably doesn't make much difference, though I guess ${datadir} is technically more correct. Just as long as it's referenced the same way everywhere.

comment:20 Changed 16 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: assignedclosed

The branch variant-descs-14482 was merged to trunk in r42662 and port resources (fetch, group, package) was moved in r42664. Marking as fixed.

Note: See TracTickets for help on using tickets.