Re: Update sticks on audio/workman
On Sun, Dec 09, 2007 at 08:55:41AM +0100, Nikolay Sturm wrote: > * Peter Hessler [2007-12-09]: > > Does pkg_add -u handle ports that can't be distributed as binaries > > (i.e. updates to Java)? Last I checked, that wasn't available. > > Not yet. It is planned to have support for sth called src-URL, which > points to your ports tree, where pkg_add will find updates to java and > other undistributable packages. Nobody (except for espie@ maybe) knows > when this feature will be committed, though. :) The feature is in, actually... it just has one `annoying' bug wrt locking the package database... thus it unlocks it temporarily in order to build packages... I think I'm going to do things the other way around, and make it possible for the ports to work with an already locked database...
Re: Update sticks on audio/workman
On Sat, Dec 08, 2007 at 07:09:52PM -0500, Jason Dixon wrote: > Yes, audio/workman has a BUILD_DEPEND of x11/view/config. I assumed there was > magic with the update target to ignore any BUILD_DEPENDs where the dependency > won't build on ARCH. I guess I'm stuck with SKIPDIR, which should be ok. > Does that feel like a bug to anyone else, or is it expected behavior? It's a limitation of the current infrastructure. You're slightly mistaken as to what's happening and why. There is no magic in make update. There isn't supposed to be any magic in make update. make update simply does build every package, as it's supposed to, and then reinstalls only whatever is already in the system. If you want to build only what's installed, you have to maintain a list of dirs more or less manually, with the current framework. That's what SRC: in PKGPATH is supposed to do eventually (it kind of works now, in fact). What you're seeing is the fact that NOT_FOR_ARCHS is not inherited from dependencies. So, xview is marked not for amd64, and it will quietly be skipped when built directly, but this is still tagged as an error when you encounter it as a dependency. It's a difficult issue to solve, because there is value in both ways. The current solution assumes non-marked build issues are problems. This is somewhat correct, because you often want to see whether something will build right at the Makefile level, without having to dig in the dependencies. No surprise. On the other hand, this often will require some heavy maintenance when a common dependency changes status, because you will then have to re-edit the broken parts in all ports of show-required-by... The correct solution would probably be to be able to stick a tag that says `warning, may not build because of this port', so that we could have it both ways, even if we forget to eventually update the port. e.g., I would just write: BROKEN_DEPENDS=::x11/xview/config in audio/workman, and it would tell me...
Re: Update sticks on audio/workman
* Peter Hessler [2007-12-09]: > Does pkg_add -u handle ports that can't be distributed as binaries > (i.e. updates to Java)? Last I checked, that wasn't available. Not yet. It is planned to have support for sth called src-URL, which points to your ports tree, where pkg_add will find updates to java and other undistributable packages. Nobody (except for espie@ maybe) knows when this feature will be committed, though. :) Nikolay
Re: Update sticks on audio/workman
On Dec 8, 2007 11:58 PM, Peter Hessler <[EMAIL PROTECTED]> wrote: > Does pkg_add -u handle ports that can't be distributed as binaries (i.e. > updates to Java)? Last I checked, that wasn't available. more or less. it'll tell you it can't find updates and ask if you wish to proceed anyway. this works fine for me (msttcorefonts, unrar, win32-codecs, ...) at least as long as the dependencies are all satisfied. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: Update sticks on audio/workman
On 2007 Dec 09 (Sun) at 07:50:41 +0100 (+0100), Nikolay Sturm wrote: :* Jason Dixon [2007-12-09]: :> Sorry, I should expand on that. What I mean is that it seems odd that :> it dives into BUILD_DEPENDS before checking to see if it's installed. :> Only after it resolves the state of its dependencies does it bother to :> see if they (or itself) is even needed. : :The ports dir is designed with developer's needs in mind, therefor it :might behave a little strange in certain situations. It looks to me as :if make update was not supposed to be used recursively as there is a :much better mechanism: pkg_add -u. Just use that one and be happy. : :Nikolay : Does pkg_add -u handle ports that can't be distributed as binaries (i.e. updates to Java)? Last I checked, that wasn't available. -- I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it. -- Clarence Darrow
Re: Update sticks on audio/workman
* Jason Dixon [2007-12-09]: > Sorry, I should expand on that. What I mean is that it seems odd that > it dives into BUILD_DEPENDS before checking to see if it's installed. > Only after it resolves the state of its dependencies does it bother to > see if they (or itself) is even needed. The ports dir is designed with developer's needs in mind, therefor it might behave a little strange in certain situations. It looks to me as if make update was not supposed to be used recursively as there is a much better mechanism: pkg_add -u. Just use that one and be happy. Nikolay
Re: Update sticks on audio/workman
On Sat, Dec 08, 2007 at 07:09:51PM -0500, Jason Dixon wrote: > On Sat, Dec 08, 2007 at 11:53:59PM +, Jacob Meuser wrote: > > On Sat, Dec 08, 2007 at 11:43:28PM +, Jacob Meuser wrote: > > > On Sat, Dec 08, 2007 at 06:30:01PM -0500, Jason Dixon wrote: > > > > I'm trying to update all installed packages by running "make update" in > > > > /usr/ports. This seems to work well except it eventually stops in > > > > audio/workman > > > > (due to a non-amd64 dependency, xview-config). But why is it trying to > > > > update > > > > audio/workman, which isn't installed anyways? > > > > > > well, you tell us. > > > > > > or didn't log your updates? > > > > > > serious lack of info in this report. > > > > and too short of a reply. > > > > there are BUILD_DEPENDS and there are RUN_DEPENDS. it's possible for a port > > to be a compile time dependency but not a run time dependency. > > > > that's probably what you are seeing. if you log your builds > > (ports/infrastructure/build/portslogger is good) you will see what > > port tried to build workman. > > I didn't know what you meant by logging my updates, so thanks for the > follow-up. > > Yes, audio/workman has a BUILD_DEPEND of x11/view/config. I assumed there was > magic with the update target to ignore any BUILD_DEPENDs where the dependency > won't build on ARCH. I guess I'm stuck with SKIPDIR, which should be ok. > > Does that feel like a bug to anyone else, or is it expected behavior? Sorry, I should expand on that. What I mean is that it seems odd that it dives into BUILD_DEPENDS before checking to see if it's installed. Only after it resolves the state of its dependencies does it bother to see if they (or itself) is even needed. Thanks, Jason
Re: Update sticks on audio/workman
On Sat, Dec 08, 2007 at 11:53:59PM +, Jacob Meuser wrote: > On Sat, Dec 08, 2007 at 11:43:28PM +, Jacob Meuser wrote: > > On Sat, Dec 08, 2007 at 06:30:01PM -0500, Jason Dixon wrote: > > > I'm trying to update all installed packages by running "make update" in > > > /usr/ports. This seems to work well except it eventually stops in > > > audio/workman > > > (due to a non-amd64 dependency, xview-config). But why is it trying to > > > update > > > audio/workman, which isn't installed anyways? > > > > well, you tell us. > > > > or didn't log your updates? > > > > serious lack of info in this report. > > and too short of a reply. > > there are BUILD_DEPENDS and there are RUN_DEPENDS. it's possible for a port > to be a compile time dependency but not a run time dependency. > > that's probably what you are seeing. if you log your builds > (ports/infrastructure/build/portslogger is good) you will see what > port tried to build workman. I didn't know what you meant by logging my updates, so thanks for the follow-up. Yes, audio/workman has a BUILD_DEPEND of x11/view/config. I assumed there was magic with the update target to ignore any BUILD_DEPENDs where the dependency won't build on ARCH. I guess I'm stuck with SKIPDIR, which should be ok. Does that feel like a bug to anyone else, or is it expected behavior? Thanks, Jason
Re: Update sticks on audio/workman
On Sat, Dec 08, 2007 at 11:43:28PM +, Jacob Meuser wrote: > On Sat, Dec 08, 2007 at 06:30:01PM -0500, Jason Dixon wrote: > > I'm trying to update all installed packages by running "make update" in > > /usr/ports. This seems to work well except it eventually stops in > > audio/workman > > (due to a non-amd64 dependency, xview-config). But why is it trying to > > update > > audio/workman, which isn't installed anyways? > > well, you tell us. > > or didn't log your updates? > > serious lack of info in this report. and too short of a reply. there are BUILD_DEPENDS and there are RUN_DEPENDS. it's possible for a port to be a compile time dependency but not a run time dependency. that's probably what you are seeing. if you log your builds (ports/infrastructure/build/portslogger is good) you will see what port tried to build workman. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: Update sticks on audio/workman
On Sat, Dec 08, 2007 at 06:30:01PM -0500, Jason Dixon wrote: > I'm trying to update all installed packages by running "make update" in > /usr/ports. This seems to work well except it eventually stops in > audio/workman > (due to a non-amd64 dependency, xview-config). But why is it trying to update > audio/workman, which isn't installed anyways? well, you tell us. or didn't log your updates? serious lack of info in this report. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Update sticks on audio/workman
I'm trying to update all installed packages by running "make update" in /usr/ports. This seems to work well except it eventually stops in audio/workman (due to a non-amd64 dependency, xview-config). But why is it trying to update audio/workman, which isn't installed anyways? Thanks, Jason
