Re: Install from Binary Archives (was Re: port install efficiency issue)

On Thu, Mar 26, 2009 at 3:19 PM, Rainer Müller wrote: > Dave Howell wrote: > > What about this: I do a "ports install widget", ports looks for a > > binary, doesn't find one that matches (in this case, the default > > options and current version), so it goes about building it. When it's > > done,

Re: Install from Binary Archives (was Re: port install efficiency issue)

Dave Howell wrote: > What about this: I do a "ports install widget", ports looks for a > binary, doesn't find one that matches (in this case, the default > options and current version), so it goes about building it. When it's > done, it says "upload compiled binary to binary archives?" I say

Install from Binary Archives (was Re: port install efficiency issue)

On Mar 22, 2009, at 22:54 , Darren Weber wrote: I In effect, every time anybody on this grid has to build a package from source, some kind of meta-package monitor can detect whether the build and install was successful and then make an inquiry of a central managment system as to whether

Re: port install efficiency issue

Darren Weber wrote: > > > On Mon, Mar 23, 2009 at 11:58 AM, Joshua Root > wrote: > > Darren Weber wrote: > > when I look at a Portfile, I also take a little time to check out > > darwinports and Debian packages to learn something about how these > > sof

Re: port install efficiency issue

On Mon, Mar 23, 2009 at 11:58 AM, Joshua Root wrote: > Darren Weber wrote: > > when I look at a Portfile, I also take a little time to check out > > darwinports and Debian packages to learn something about how these > > software are built and distributed. > > I'm confused - is this a slip of the

Re: port install efficiency issue

Darren Weber wrote: > when I look at a Portfile, I also take a little time to check out > darwinports and Debian packages to learn something about how these > software are built and distributed. I'm confused - is this a slip of the keyboard? DarwinPorts no longer exists, the name changed to MacPo

Re: port install efficiency issue

On Mon, Mar 23, 2009 at 12:47 AM, Ryan Schmidt wrote: > > On Mar 22, 2009, at 13:19, Darren Weber wrote: > > On balance, I'm both impressed and disappointed with the complexity of the >> macports system to date. For example, dependency resolution needs a lot of >> work during upgrades, binary di

Re: port install efficiency issue

On Mar 23, 2009, at 1:08 AM, Frank J. R. Hanstick wrote: On Mar 23, 2009, at 12:47 AM, Ryan Schmidt wrote: On Mar 22, 2009, at 13:19, Darren Weber wrote: On balance, I'm both impressed and disappointed with the complexity of the macports system to date. For example, dependency resolut

Re: port install efficiency issue

On Mar 23, 2009, at 12:47 AM, Ryan Schmidt wrote: On Mar 22, 2009, at 13:19, Darren Weber wrote: On balance, I'm both impressed and disappointed with the complexity of the macports system to date. For example, dependency resolution needs a lot of work during upgrades, binary distributi

Re: port install efficiency issue

On Mar 22, 2009, at 13:19, Darren Weber wrote: On balance, I'm both impressed and disappointed with the complexity of the macports system to date. For example, dependency resolution needs a lot of work during upgrades, binary distributions are a great idea in the making (perhaps forever i

Re: port install efficiency issue

Is it possible to create a distributed build system that uses Xgrid, to allow all macport users the option of adding their machine to a distributed macports build system? In effect, every time anybody on this grid has to build a package from source, some kind of meta-package monitor can detect whe

Re: port install efficiency issue

Scott Haneda wrote: > Can we talk more about this? I have the ability to host such a build > farm. Now, I could not host one machine, of every architecture, of > every OS, I just do not have the room in colocation. > > I do have quite a bit of room if we go 1U though. So 2 1U machines, a > PPC

Re: port install efficiency issue

Daniel J. Luke wrote: > On Mar 22, 2009, at 9:34 AM, Rainer Müller wrote: >> Ryan Schmidt wrote: I think port not only pays attention to epoch/version/revision but also the timestamp of Portfile; when Portfile is newer than the install, even when the versioning says it's al

Re: port install efficiency issue

Can we talk more about this? I have the ability to host such a build farm. Now, I could not host one machine, of every architecture, of every OS, I just do not have the room in colocation. I do have quite a bit of room if we go 1U though. So 2 1U machines, a PPC and a Intel, and I would

Re: port install efficiency issue

Daniel J. Luke wrote: >> If nobody can think of a valid use for this check we should just >> drop it. > > It is somewhat useful when one is developing a new port (since you > don't have to remember to clean before you rebuild after changing the > Portfile), and there's the -o flag one can us

Re: port install efficiency issue

On Sun, Mar 22, 2009 at 11:19:35AM -0700, Darren Weber said: [...] > > On balance, I'm both impressed and disappointed with the complexity of the > macports system to date. For example, dependency resolution needs a lot of > work during upgrades, What do you mean, performance-wise? If so, that'

Re: port install efficiency issue

On Mar 22, 2009, at 4:16 PM, Daniel J. Luke wrote: On Mar 22, 2009, at 9:34 AM, Rainer Müller wrote: Ryan Schmidt wrote: I think port not only pays attention to epoch/version/revision but also the timestamp of Portfile; when Portfile is newer than the install, even when the versioning says it

Re: port install efficiency issue

On Mar 22, 2009, at 9:34 AM, Rainer Müller wrote: Ryan Schmidt wrote: I think port not only pays attention to epoch/version/revision but also the timestamp of Portfile; when Portfile is newer than the install, even when the versioning says it's already installed, it'll run again. I would not h

Re: port install efficiency issue

2009/3/22 Frank J. R. Hanstick > Hello, > Wouldn't it be better and faster to do the check at request time rather > than wait until everything has been done and then request if an update is > wanted rather than an install? > Frank > Yes, sounds reasonable. Also, my apologies! Macports is grea

Re: port install efficiency issue

Hello, Wouldn't it be better and faster to do the check at request time rather than wait until everything has been done and then request if an update is wanted rather than an install? Frank On Mar 22, 2009, at 6:56 AM, Rainer Müller wrote: Darren Weber wrote: What is up with port? It jus

Re: port install efficiency issue

Darren Weber wrote: What is up with port? It just ran for about 15 mins to build a package that is already installed. If I were to work on the same damn thing, repeating it all day, day after day, I would get the sack pretty quickly. Just think of the useless load on the network and the server

Re: port install efficiency issue

On Mar 21, 2009, at 8:10 PM, Darren Weber wrote: What is up with port? It just ran for about 15 mins to build a package that is already installed. If I were to work on the same damn thing, repeating it all day, day after day, I would get the sack pretty quickly. Just think of the usel

Re: port install efficiency issue

Darren Weber wrote: > What is up with port? It just ran for about 15 mins to build a package > that is already installed. If I were to work on the same damn thing, > repeating it all day, day after day, I would get the sack pretty > quickly. Just think of the useless load on the network and the

Re: port install efficiency issue

Ryan Schmidt wrote: >> I think port not only pays attention to epoch/version/revision but >> also the >> timestamp of Portfile; when Portfile is newer than the install, >> even when >> the versioning says it's already installed, it'll run again. > > I would not have expected that. > > If a re

Re: port install efficiency issue

Ryan Schmidt wrote: * I was under the impression Mac Ports was sort of to replace Fink, is that not the case? What are the pros and cons, differences? Is Fink still active? Fink and MacPorts are both package management systems for Mac OS X. I myself switched from Fink to what is now Mac

Re: port install efficiency issue

On Mar 22, 2009, at 02:33, Scott Haneda wrote: On Mar 21, 2009, at 9:58 PM, Ryan Schmidt wrote: We should keep our comments constructive. I'd like to minimize disparaging remarks about MacPorts coming from macports.org email addresses. Question of general curiosity here. I am asking thi

Re: port install efficiency issue

On Mar 22, 2009, at 02:34, Bryan Blackburn wrote: On Sat, Mar 21, 2009 at 11:58:33PM -0500, Ryan Schmidt said: [...] There are valid reasons for wanting to rebuild a port that's already installed. But it's probably reasonable to require the use of the - f flag in those situations. And I bel

Re: port install efficiency issue

On Sat, Mar 21, 2009 at 11:58:33PM -0500, Ryan Schmidt said: [...] > > There are valid reasons for wanting to rebuild a port that's already > installed. But it's probably reasonable to require the use of the -f flag > in those situations. And I believe that's what is supposed to be > implement

Re: port install efficiency issue

On Mar 21, 2009, at 9:58 PM, Ryan Schmidt wrote: On Mar 21, 2009, at 22:10, Darren Weber wrote: What is up with port? It just ran for about 15 mins to build a package that is already installed. If I were to work on the same damn thing, repeating it all day, day after day, I would get the

Re: port install efficiency issue

On Mar 21, 2009, at 11:10 PM, Darren Weber wrote: What is up with port? It just ran for about 15 mins to build a package that is already installed. If I were to work on the same damn thing, repeating it all day, day after day, I would get the sack pretty quickly. Just think of the use

Re: port install efficiency issue

On Mar 21, 2009, at 22:10, Darren Weber wrote: What is up with port? It just ran for about 15 mins to build a package that is already installed. If I were to work on the same damn thing, repeating it all day, day after day, I would get the sack pretty quickly. Just think of the useless

Re: port install efficiency issue

On Mar 21, 2009, at 11:10 PM, Darren Weber wrote: What is up with port? It just ran for about 15 mins to build a package that is already installed. It doesn't usually do this for me. Are you running the current released version or are you running the development version? Perhaps you have

port install efficiency issue

What is up with port? It just ran for about 15 mins to build a package that is already installed. If I were to work on the same damn thing, repeating it all day, day after day, I would get the sack pretty quickly. Just think of the useless load on the network and the servers for all those futile