Re: RFC: changes to ports infrastructure
Okay, I've started moving a lot of things. I've moved aggressively stuff that is internal to the ports tree (all the scripts used by bsd.port.mk) and dpb3 (renamed to dpb, as I hope to finally deprecate the other dpb). I'm probably going to document this part, and then do a second pass for the rest...
RFC: changes to ports infrastructure
I want to tweak the directory structure for ports. I'd like to go for a lot of stuff to ports/infrastructure/bin ports/infrastructure/lib ports/infrastructure/man the current setup (build, fetch, install, package) is my mistake, and frankly it sucks. Some of the scripts are callable outside of bsd.port.mk, and you have to remember the path. There is no standard documentation out of the scripts, and there are a few perl modules that could use one single place. I would keep db, plist, templates. I don't think they're that confusing. The only drawback is that we're going to lose cvs history. doesn't seem like such a big problem to me. Also, third party may lose compatibility as scripts move around. That's easy to solve with symlinks, so I don't care too much. Did I miss anything ?
Re: RFC: changes to ports infrastructure
On 2010/08/19 11:55, Marc Espie wrote: I want to tweak the directory structure for ports. I'd like to go for a lot of stuff to ports/infrastructure/bin ports/infrastructure/lib ports/infrastructure/man Yes please. Two things; - does mk move? - can we add ports/infrastructure/man to man.conf?
Re: RFC: changes to ports infrastructure
On Thu, Aug 19, 2010 at 11:09:14AM +0100, Stuart Henderson wrote: On 2010/08/19 11:55, Marc Espie wrote: I want to tweak the directory structure for ports. I'd like to go for a lot of stuff to ports/infrastructure/bin ports/infrastructure/lib ports/infrastructure/man Yes please. Two things; - does mk move? no. - can we add ports/infrastructure/man to man.conf? globally ? no idea. on my ports boxes: definitely.
Re: RFC: changes to ports infrastructure
On Thu, Aug 19, 2010 at 11:55:22AM +0200, Marc Espie wrote: I want to tweak the directory structure for ports. I'd like to go for a lot of stuff to ports/infrastructure/bin ports/infrastructure/lib ports/infrastructure/man the current setup (build, fetch, install, package) is my mistake, and frankly it sucks. Some of the scripts are callable outside of bsd.port.mk, and you have to remember the path. There is no standard documentation out of the scripts, and there are a few perl modules that could use one single place. I would keep db, plist, templates. I don't think they're that confusing. The only drawback is that we're going to lose cvs history. doesn't seem like such a big problem to me. Also, third party may lose compatibility as scripts move around. That's easy to solve with symlinks, so I don't care too much. Did I miss anything ? I think losing cvs history for mk/ would be worst. But since that dir doesn't move I don't care too much for losing the history of the other files. I can only add a yes please, as the current setup is rather confusing. Cheers, Jasper -- Stay Hungry. Stay Foolish.
Re: RFC: changes to ports infrastructure
* Marc Espie es...@nerim.net [100819 06:00]: I want to tweak the directory structure for ports. I'd like to go for a lot of stuff to ports/infrastructure/bin ports/infrastructure/lib ports/infrastructure/man the current setup (build, fetch, install, package) is my mistake, and frankly it sucks. Some of the scripts are callable outside of bsd.port.mk, and you have to remember the path. There is no standard documentation out of the scripts, and there are a few perl modules that could use one single place. I would keep db, plist, templates. I don't think they're that confusing. The only drawback is that we're going to lose cvs history. doesn't seem like such a big problem to me. Also, third party may lose compatibility as scripts move around. That's easy to solve with symlinks, so I don't care too much. Did I miss anything ? FWIW, I'm ok with this change. I reviewed the contents of each directory and have no concerns. Best regards, jim@
Re: RFC: changes to ports infrastructure
On Thu, Aug 19, 2010 at 02:46:44PM +0200, Joachim Schipper wrote: On Thu, Aug 19, 2010 at 11:55:22AM +0200, Marc Espie wrote: I want to tweak the directory structure for ports. I'd like to go for a lot of stuff to ports/infrastructure/bin ports/infrastructure/lib ports/infrastructure/man the current setup (build, fetch, install, package) is my mistake, and frankly it sucks. Some of the scripts are callable outside of bsd.port.mk, and you have to remember the path. There is no standard documentation out of the scripts, and there are a few perl modules that could use one single place. I would keep db, plist, templates. I don't think they're that confusing. The only drawback is that we're going to lose cvs history. doesn't seem like such a big problem to me. Also, third party may lose compatibility as scripts move around. That's easy to solve with symlinks, so I don't care too much. Did I miss anything ? Something you may also want to consider: currently, you can't really install a partial ports tree. If all modules were kept in e.g. ports/infrastructure/modules, it may be possible to install only a hypothetical ports-infrastructure.tar.gz (like sys.tar.gz, but for ports) and a couple of individual ports (e.g. under mystuff/). This would make it very easy to upgrade just one package on a -stable system (e.g. to fix a security issue or get an updated port from -current). It would be even better if FETCH_PACKAGES could be made to work in this scenario, but that's not required. This is in no way a must-have feature, but if you're moving stuff anyway... No-go. You also need proper depends to compute default pkgnames for the package, so you mostly need the full ports tree anyways. And modules was specifically designed to be modular, with no central place... I *could* have bsd.port.mk auto-checkout directories when needed with a specific cvs script, But considering the small size of the ports tree, it is probably one more useless feature. though.
