portname based distfiles directory
Up until now we've uploaded tarballs and other distfiles to our distfiles section in svn to user named directories, together with a / distfiles/general dir for unmaintained ports. It's been discussed that using port name based directories is more natural and straight forward for the purpose of the /distfiles directory, so I wanted to poll you all on making such move. Other than logical organization, other benefits would be not needing the general dir any longer and the fetch proc finding the distfiles on the first hit, as seen by the following example: -> pwd trunk/dports/net/libpcap -> grep master_sites Portfile #master_sites ${homepage}release/ master_sites macports -> port -df fetch ---snip--- ---> Fetching libpcap DEBUG: Executing org.macports.fetch (libpcap) ---> libpcap-0.9.5.tar.gz doesn't seem to exist in /opt/local/var/ macports/distfiles/libpcap ---> Attempting to fetch libpcap-0.9.5.tar.gz from http:// svn.macports.org/repository/macports/distfiles/libpcap % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 423k 100 423k 0 0 26031 0 0:00:16 0:00:16 --:--:-- 22644 Moving to port name based directories would still allow us to use user named ones as they currently exist, if need be, thanks to the "macports:<user>" syntax for our distfiles in the fetch proc. So, what says you'all? Regards,... -jmpp
On Wed, Aug 08, 2007 at 02:24:41PM -0400, Juan Manuel Palacios wrote:
Up until now we've uploaded tarballs and other distfiles to our distfiles section in svn to user named directories, together with a / distfiles/general dir for unmaintained ports. It's been discussed that using port name based directories is more natural and straight forward for the purpose of the /distfiles directory, so I wanted to poll you all on making such move. Other than logical organization, other benefits would be not needing the general dir any longer and the fetch proc finding the distfiles on the first hit, as seen by the following example:
[snip example]
Moving to port name based directories would still allow us to use user named ones as they currently exist, if need be, thanks to the "macports:<user>" syntax for our distfiles in the fetch proc.
So, what says you'all? Regards,...
I agree, in fact I'd sent a similar note the other day, only to (now) discover it'd been auto-rejected:
I think we should change the policy to using port-specific directories, i.e. .../distfiles/${portname} (i.e. .../distfiles/slib) as 'port' is already looking there, thus no additions to Portfiles are required and there's a sensible linkage between the port and the distfile. As well, if a maintainer decides to no longer maintain a particular port, the distfile would need to be moved out of that person's distfile directory and either to general/ or to another maintainer's directory.
-eric
Juan Manuel Palacios wrote:
Up until now we've uploaded tarballs and other distfiles to our distfiles section in svn to user named directories, together with a /distfiles/general dir for unmaintained ports. It's been discussed that using port name based directories is more natural and straight forward for the purpose of the /distfiles directory, so I wanted to poll you all on making such move.
I have two proposals: 1) distfiles/${category}/${name} Hierarchy matching the ports tree. Using name only results in a long list if we add files for more ports. 2) trunk/dports/${category}/${name}/distfiles Although that would mix up sources only and binaries in the same tree, if that matters (e.g. on branching/tagging). But with this solution all files belonging to a port would be together at one place. Rainer
On Aug 8, 2007, at 19:06, Rainer Müller wrote:
Juan Manuel Palacios wrote:
Up until now we've uploaded tarballs and other distfiles to our distfiles section in svn to user named directories, together with a /distfiles/general dir for unmaintained ports. It's been discussed that using port name based directories is more natural and straight forward for the purpose of the /distfiles directory, so I wanted to poll you all on making such move.
No objection.
I have two proposals:
1) distfiles/${category}/${name} Hierarchy matching the ports tree. Using name only results in a long list if we add files for more ports.
If you like. I don't care one way or the other.
2) trunk/dports/${category}/${name}/distfiles Although that would mix up sources only and binaries in the same tree, if that matters (e.g. on branching/tagging). But with this solution all files belonging to a port would be together at one place.
Objection. a) In the long term, we want to get the portfiles *out* of the trunk since they don't belong there anyway, not put more things into the trunk. See previous messages from jmpp, I believe. b) The dports directory is automatically downloaded to all clients via sync and selfupdate. We don't want all clients to have to automatically receive all these distfiles too, since a high percentage of people won't install those particular ports anyway. So I see it as highly desirable to separate the portfiles, which everyone will always download, from the distfiles, which will only be downloaded as needed.
So guys, all of you in the Cc list with user named directories in the /distfiles section of our repo, could we start this move and adapt the Portfiles accordingly? Thanks! On Aug 8, 2007, at 10:57 PM, Ryan Schmidt wrote:
On Aug 8, 2007, at 19:06, Rainer Müller wrote:
Juan Manuel Palacios wrote:
Up until now we've uploaded tarballs and other distfiles to our distfiles section in svn to user named directories, together with a /distfiles/general dir for unmaintained ports. It's been discussed that using port name based directories is more natural and straight forward for the purpose of the /distfiles directory, so I wanted to poll you all on making such move.
No objection.
I have two proposals:
1) distfiles/${category}/${name} Hierarchy matching the ports tree. Using name only results in a long list if we add files for more ports.
If you like. I don't care one way or the other.
I'd prefer a flat file layout, as that allows us to simply list "macports" as the master site and have the fetch procedure find the distfile on the first try. A Category level would imply further tweaking, unnecessary for now in my opinion.
2) trunk/dports/${category}/${name}/distfiles Although that would mix up sources only and binaries in the same tree, if that matters (e.g. on branching/tagging). But with this solution all files belonging to a port would be together at one place.
Objection. a) In the long term, we want to get the portfiles *out* of the trunk since they don't belong there anyway, not put more things into the trunk. See previous messages from jmpp, I believe. b) The dports directory is automatically downloaded to all clients via sync and selfupdate. We don't want all clients to have to automatically receive all these distfiles too, since a high percentage of people won't install those particular ports anyway. So I see it as highly desirable to separate the portfiles, which everyone will always download, from the distfiles, which will only be downloaded as needed.
I tried getting the ports dir out of trunk but was met with some opposition (I still believe it doesn't belong there!). But in any case, adding the ditfiles to the ports dir, regardless of where the latter resides, is not the way to go. Regards,... -jmpp
Juan Manuel Palacios wrote:
So guys, all of you in the Cc list with user named directories in the /distfiles section of our repo, could we start this move and adapt the Portfiles accordingly? Thanks!
I'll move the tarballs from directory "afb" over to "MacPorts" then, right ? I think I also added bzip2-1.0.4.tar.gz to "general", rather than "bzip2"... --anders
On Aug 14, 2007, at 5:29 AM, Anders F Björklund wrote:
Juan Manuel Palacios wrote:
So guys, all of you in the Cc list with user named directories in the /distfiles section of our repo, could we start this move and adapt the Portfiles accordingly? Thanks!
I'll move the tarballs from directory "afb" over to "MacPorts" then, right ?
In theory, yes. You have tarballs for MacPorts itself in your distfiles dir, so they "should" be moved to /distfiles/MacPorts (properly capitalized, per the port name). And why do I quote...? 'Cause we have /downloads/MacPorts-1.5.0/ holding the official tarballs & dmg's for the project, so I don't see why we need to duplicate them into the distfiles section (true that we could merge downloads & distfiles after moving the latter to per port naming, but that's another discussion). If for some reason you require tarballs for the specific MacPorts versions you now have in /distfiles/afb, feel free to create them off our sources (base/Makefile automates this in an elegant way, ping me if you need any pointers) and upload them to the downloads section. Regards,... -jmpp
Juan Manuel Palacios wrote:
I'll move the tarballs from directory "afb" over to "MacPorts" then, right ?
In theory, yes. You have tarballs for MacPorts itself in your distfiles dir, so they "should" be moved to /distfiles/MacPorts (properly capitalized, per the port name). And why do I quote...? 'Cause we have /downloads/MacPorts-1.5.0/ holding the official tarballs & dmg's for the project, so I don't see why we need to duplicate them into the distfiles section (true that we could merge downloads & distfiles after moving the latter to per port naming, but that's another discussion). If for some reason you require tarballs for the specific MacPorts versions you now have in /distfiles/afb, feel free to create them off our sources (base/Makefile automates this in an elegant way, ping me if you need any pointers) and upload them to the downloads section.
I only need the distfiles (which were indeed made using distfromsvn, like the regular releases) on the platforms where "selfupdate" is broken, and they need an URL for the package managers to fetch them from (asking users to build their own tarballs from SVN seems like a bad idea). Having "1.4.42" and "1.5.11" in the main /downloads might confuse users though, so I'm fine with having them in a machine-only location (such as /distfiles) as long as it is accessible. Although I do think that having one offical tarball for each offical release ain't such a bad idea in general... --anders
On Aug 14, 2007, at 6:23 PM, Anders F Björklund wrote:
Having "1.4.42" and "1.5.11" in the main /downloads might confuse users though, so I'm fine with having them in a machine-only location (such as /distfiles) as long as it is accessible.
Yeah, it make sense, lets keep them in /distfiles for now then. Would love it if other maintainers started moving their distfiles to per port directories within /distfiles too! Regards,... -jmpp
Juan Manuel Palacios:
Having "1.4.42" and "1.5.11" in the main /downloads might confuse users though, so I'm fine with having them in a machine-only location (such as /distfiles) as long as it is accessible.
Yeah, it make sense, lets keep them in /distfiles for now then. Would love it if other maintainers started moving their distfiles to per port directories within /distfiles too!
I'll move them to "MacPorts" once 1.5.2 is out (replacing current 1.5.1 tarball) --anders
participants (5)
-
Anders F Björklund
-
Eric Hall
-
Juan Manuel Palacios
-
Rainer Müller
-
Ryan Schmidt