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...
Re: RFC: changes to ports infrastructure
Marc Espie [2010-08-19, 11:55:22]: > 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 ? Good plan, ok for me.
Re: RFC: changes to ports infrastructure
On Thu, Aug 19, 2010 at 03:06:09PM +0200, Marc Espie wrote: > 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. > > > Did I miss anything ? > > > > [Y]ou 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. > > No-go. You also need proper depends to compute default pkgnames for the > package, so you mostly need the full ports tree anyways. Yeah, hadn't thought of that. Deriving that information only from installed packages is probably not feasible. > 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. I admit, that wouldn't be too useful. Sorry for bothering you! Joachim -- TFMotD: motd (5) - message of the day
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.
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 ? 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... Joachim -- TFMotD: sigvec (3) - software signal facilities
Re: RFC: changes to ports infrastructure
* Marc Espie [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 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
On Thu, 19 Aug 2010, 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; Yes please N02 :) > - does mk move? > - can we add ports/infrastructure/man to man.conf? That would be a very welcome addition imho. -- Antoine
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 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?
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 ?
