Re: Slight problem with make actual-package-depends with ports
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Wed, 18 Jul 2007 09:16:56 -0500): Alexander Leidinger wrote: Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Tue, 17 Jul 2007 19:46:11 -0500): It seems to me that the cure is to slightly change make actual-package-depends so that if the port is already installed, it just uses +CONTENTS. This is wrong. What if you have a port installed and you want to rebuild the same version with other OPTIONS which changes the +CONTENTS file? If I read your patch right, it will use the wrong contents... You cannot install the port until you have first deinstalled it (unless you use some kind of FORCE option, and it is reasonable that this would mess things up). Thus at installation time, +CONTENTS will never exist. But I take your point if perhaps you do need to use some kind of FORCE option. Yes, sorry for not being clear. Sometimes I use FORCE_PKG_REGISTER in case I really know what I'm doing. With the change you proposed, this would be only ok, if you install the port with the same options again, but not when you install with options which change the plist. Bye, Alexander. -- 1) You can't win 2) You can't break even 3) You can't even quit the game http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slight problem with make actual-package-depends with ports
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Wed, 18 Jul 2007 10:11:47 -0500): Alexander Leidinger wrote: Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Tue, 17 Jul 2007 19:46:11 -0500): I appreciate that most people won't have this problem, but it has bitten me. After you have made and installed a port, but don't clean it, and then made a bunch of other ports, if you go back to the original port and then do make package, then +CONTENTS can be a bit messed up for the package. This is because the creation of other ports might disturb Can you please give an example what messed up means in this context, e.g. post a diff between a good an a bad contents file? And what actions you did to get this difference? _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. You mean that if you create a leaf package and then rebuild a package which is in the middle of the dependency tree with options which change the dependency graph of the leaf package you get problems? If yes: this has to be expected. You need to rebuild the packages in the right order. In other words, you have to perform the make package right after the make install before you install any other ports. Otherwise you have to use pkg_create -b (which I have recently started doing). I think the old version of getting the package dependency should fail in a similar way if you don't issue make package before installing other ports (where you change the options in a way that the dependency list changes). This happens to me because I make all my ports on one machine and then copy them as packages to other machines. Then on the other machines, the structure of /var/db/pkg gets a bit messed up and pkg_delete -r malfunctions. I have a lot of jails where I use the packages build in other jails. I haven't seen a problem there. The package install doesn't change the +CONTENTS files, so /var/db/pkg should be messed up on the build machine too... It seems to me that the cure is to slightly change make actual-package-depends so that if the port is already installed, it just uses +CONTENTS. This is wrong. What if you have a port installed and you want to rebuild the same version with other OPTIONS which changes the +CONTENTS file? If I read your patch right, it will use the wrong contents... The other option (to allow the users to do make package much later than make install) would be to have two different actual-package-depends, one for make install, and the other for make package. It may be good to compare the way you do the package creation by hand with the way bsd.port.mk is doing it. Maybe something can be improved... Bye, Alexander. -- You can search for documentation on a keyword by typing apropos keyword http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problems with +CONTENTS being messed up by pkg_delete -f
Stephen Montgomery-Smith: If you pkg_delete -f a package and then install the port again (but after it has been bumped up a version), then the +CONTENTS of ports that require the original port will be incorrect. This apparently messes up programs like portmanager. There is a sense in which one should never do pkg_delete -f and expect /var/db/pkg to keep its integrety - on the other hand this is exactly what make deinstall does. My feeling is that the integrety of /var/db/pkg should be maintained across a make deinstall and subsequent make install of a bumped version of the port. The tricky point is when the dependencies change with a version bump. It will also be difficult if the user changes make config options (which commonly affect dependencies - consider my favorite WITHOUT_NLS knob) and reinstalls. My feeling is that tackling this with a general solution would be nice to have - but the details and corner cases are pretty difficult. A further benefit of this approach is that one could also accurately reconstruct the +REQUIRED_BY of the port just reinstalled - right now this is left empty and thus inaccurate. Well. This is true, but on the other hand +REQUIRED_BY basically just duplicates information that we already have in the ports tree. Most ports management packages that we have (including my homegrown perl script) don't rely on information contained in +REQUIRED_BY, but just start with what is already in the ports tree. Which leads to the question whether +REQUIRED_BY is still of much value at all... Helge Atos Origin GmbH, Theodor-Althoff-Str. 47, D-45133 Essen, Postfach 100 123, D-45001 Essen Telefon: +49 201 4305 0, Fax: +49 201 4305 689095, www.atosorigin.de Dresdner Bank AG, Hamburg: Kto. 0954411200, BLZ 200 800 00, Swift Code DRESDEFF200, IBAN DE6920080954411200 Geschäftsführer: Dominique Illien, Handelsregister Essen HRB 19354, Ust.-ID.-Nr.: DE147861238 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with +CONTENTS being messed up by pkg_delete -f
I'm dropping -hackers since this is a ports issue. Stephen Montgomery-Smith wrote: If you pkg_delete -f a package and then install the port again (but after it has been bumped up a version), then the +CONTENTS of ports that require the original port will be incorrect. This apparently messes up programs like portmanager. There is a sense in which one should never do pkg_delete -f and expect /var/db/pkg to keep its integrety Not a sense, you simply shouldn't expect things to work properly if you do this. The -f flag _means_, do this even if it's a bad idea. Now that said, before I wrote portmaster I used to do this all the time, and almost never had a problem. I added a routine to clean up the +CONTENTS and +REQUIRED_BY files to portmaster almost as an afterthought, and I'm still ambivalent over when it's right to delete stuff from +CONTENTS, and when it isn't. The good news is that if you have weird stale stuff in +CONTENTS files portmaster will try to fix it for you at best, and at worst it won't choke on it. on the other hand this is exactly what make deinstall does. I'm not sure I see the relevance of this bit. My feeling is that the integrety of /var/db/pkg should be maintained across a make deinstall and subsequent make install of a bumped version of the port. Can you define what you mean by integrity? This is my suggestion. When a pkg_delete -f is executed, it looks through +REQUIRED_BY of the port it is going to delete, How do you know that file is up to date? :) and modifies the +CONTENTS file of each of them, replacing lines like @pkgdep xineramaproto-1.1.2 @comment DEPORIGIN:x11/xineramaproto to maybe something like @comment DELDEPORIGIN:x11/xineramaproto My gut feeling is that this is overkill. I'll have to give it some thought though. (deleted dependency origin). A subsequent make install of x11/xineramaproto should look through the +CONTENTS of all entries in /var/db/pkg and change these lines to something like @pkgdep xineramaproto-1.1.3 @comment DEPORIGIN:x11/xineramaproto A further benefit of this approach is that one could also accurately reconstruct the +REQUIRED_BY of the port just reinstalled - right now this is left empty and thus inaccurate. Doing what you suggested isn't necessary to rebuild the +REQUIRED_BY file. What portmaster does (assuming we are upgrading a port that is depended on) is: 1. Build the new version of the port 2. grep for the short name of the port in existing +CONTENTS files and save the sorted result 3. sort the +REQUIRED_BY file and compare the two 4. If they match, we proceed, if not we give the user the opportunity to correct the +REQUIRED_BY file 5. Once that is sorted out, we pkg_delete -f the old and install the new version of the port 6. Update the pkgdep line in each +CONTENTS file for the ports listed in the new +REQUIRED_BY file 7. Install the new +REQUIRED_BY file In this way everything gets updated from scratch, so you're left with stuff in a consistent state. In my experience, you have to do at least that much work to make sure that you leave everything better than you found it, and if there are missing dependencies in +REQUIRED_BY you pretty much have to give the user options to fix it because it's hard to get all the edge cases right programmatically. Now portmaster can also fix this for you if you pkg_delete -f something by hand, and then use portmaster to install the new version. What portmaster does _not_ do at this time, and one of the things I'm ambivalent about adding is what you actually posted about; detecting duplicate entries with the same DEPORIGIN and reducing them down to one entry. I've resisted adding that because it's not particularly easy (or fast, which I'm more interested in) to do that in sh, having duplicates doesn't hurt anything (as far as I've ever been able to tell), and the problem will be erased the next time the user rebuilds the port that has the dependency. If someone feels strongly that fixing this is important, I can look at this again, but my gut feeling is that it isn't a very important problem. Now if it's true that these duplicates do break portmanager, then it does become more important to me, since I don't want to do anything in portmaster that will negatively impact the ability to use a different ports management tool. So if we get a definitive answer on this I'll definitely take another look. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Porting a Python 2.5 dependent software.
Hi, I'm trying to port a package on FreeBSD. The package depends on Python v.2.5 (which is not default on FreeBSD 6.2-RELEASE), and some python modules. Now, the problem is that dependent python modules are already installed in Python v2.4 PYTHON_SITELIBDIR directory. So when I execute install target for my port, install target of python modules (dependencies) are also invoked, and since they're already installed (but in a different PYTHON_SITELIBDIR), I get following error: -- begin error -- === Installing for py25-numeric-24.2 === py25-numeric-24.2 depends on file: /usr/local/bin/python2.5 - found === Generating temporary packing list === Checking if math/py-numeric already installed === An older version of math/py-numeric is already installed (py24-numeric-24.2) You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of math/py-numeric without deleting it first, set the variable FORCE_PKG_REGISTER in your environment or the make install command line. *** Error code 1 Stop in /usr/ports/math/py-numeric. -- end error -- I've already set USE_PYTHON=2.5+ in my port's Makefile. Any ideas what should I do here ? Shall I wait for Python 2.5 to become default for FreeBSD. BtW, I'm trying to port Redhat Online Desktop[1] to FreeBSD. [1] http://developer.mugshot.org/wiki/Online_Desktop_Project Thanks in advance, Ashish Shukla -- Ashish Shukla Wah Java !! आशीष शुक्ल weblog: http://wahjava.wordpress.com/ ,= ,-_-. =. | A: Yes.| ((_/)o o(\_)) | Q: Are you sure? | `-'(. .)`-' | A: Because it reverses the logical flow of conversation. | \_/ | Q: Why is top posting frowned upon? | pgpYMGEYChM8Y.pgp Description: PGP signature
Re: Problems with +CONTENTS being messed up by pkg_delete -f
On Wed, 2007-07-18 at 21:18 -0700, Garrett Cooper wrote: Stephen, I admire your willingness to help, but I believe that Robert should be the one detailing the problem not you. That way too much confusion doesn't get aroused on the list(s). I'm going to remove hackers@ from the CC list because this almost exclusively pertains to [EMAIL PROTECTED] -Garrett Ok, so the issue that I hope to address is not really a portmanager issue. The original version of package-depends always listed the current version (from ports) in the +CONTENTS file. When that list was passed to sort -u, you ended up with a single dependency for each origin. The new way it takes each direct dependency and adds those, then recursively parses the +CONTENTS file of each of those and adds those entries and finally passes the whole thing to sort -u. This allows for multiple dependencies with the same origin to be listed in the +CONTENTS file. As an example... port a depends on b and c. Port c has a version bump and is updated but technically b doesn't require an update. Now if port a is updated it will get the current version of c and also the old version of c from b. robert. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with +CONTENTS being messed up by pkg_delete -f
Robert Noland wrote: Ok, so the issue that I hope to address is not really a portmanager issue. The original version of package-depends Just to be clear, you're talking about the target in bsd.port.mk, right? I've snipped the rest of your post since I get a feeling that what you're trying to get at might be important, but I cannot parse it even after rereading several times. Can you provide a concrete example, with names of actual ports so that we can look into this further? Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
recent updates to portsmon.freebsd.org
I have just updated portsmon to the most recent development code. Most of this code has to do with the ability to create dependency graphs of failed or broken ports, and is not yet totally automated; thus, it is not (yet) visible to users. Other code has to do with internal schema changes. The most user-visible change is the new ability to be able to show a page of ports that fail on only one build environment. For example: http://portsmon.freebsd.org/portsconcordanceforbuildenv.py?buildenv=i386-7-fullbuildenv2=i386-6-full will show you the list of ports that fail on i386 but only on -current, not on -stable. Please let me know if you experience any problems with the upgrade. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with +CONTENTS being messed up by pkg_delete -f
Doug Barton wrote: Robert Noland wrote: Ok, so the issue that I hope to address is not really a portmanager issue. The original version of package-depends Just to be clear, you're talking about the target in bsd.port.mk, right? I've snipped the rest of your post since I get a feeling that what you're trying to get at might be important, but I cannot parse it even after rereading several times. Can you provide a concrete example, with names of actual ports so that we can look into this further? Doug Personally I think that: 1. Versions shouldn't matter when calculating absolute dependencies (i.e. net/samba may depend on popt). 2. If versions do change for a dependent package, the packages dependent on the changed package should also be rebuilt. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]