New Ticket     Wiki     Browse Source     Timeline     Roadmap     Bug Reports     Search

Ticket #14553 (closed enhancement: fixed)

Opened 16 months ago

Last modified 7 months ago

RFE: Move portgroups into the ports tree

Reported by: raimue@… Owned by: raimue@…
Priority: Normal Milestone: MacPorts 1.7.0
Component: ports Version: 1.6.0
Keywords: portgroups Cc: nox@…, ryandesign@…, mcalhoun@…, 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

  Changed 15 months ago by raimue@…

  • status changed from new to assigned

  Changed 14 months ago by raimue@…

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.

  Changed 14 months ago by jmr@…

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

  Changed 14 months ago by nox@…

  • cc nox@… added

Cc Me!

  Changed 14 months ago by nox@…

Why ".resources"? Why an hidden directory?

  Changed 14 months ago by jmr@…

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

  Changed 14 months ago by raimue@…

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.

  Changed 10 months ago by ryandesign@…

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

follow-up: ↓ 11   Changed 10 months ago by 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.

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.

  Changed 9 months ago by mcalhoun@…

  • cc mcalhoun@… added

Cc Me!

in reply to: ↑ 9   Changed 9 months ago by jmr@…

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?

  Changed 9 months ago by febeling@…

  • cc febeling@… added

Cc Me!

  Changed 9 months ago by raimue@…

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.

  Changed 9 months 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.

  Changed 9 months ago by raimue@…

  • milestone changed from MacPorts base enhancements to MacPorts 1.7.0

  Changed 8 months 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?

follow-up: ↓ 18   Changed 7 months ago by jmr@…

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

in reply to: ↑ 17   Changed 7 months 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?

  Changed 7 months ago by jmr@…

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.

  Changed 7 months ago by raimue@…

  • status changed from assigned to closed
  • resolution set to fixed

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.