Re: Portmaster with package support ready for beta testing
On Tue, Nov 10, 2009 at 11:46:17PM +0100, Dominic Fandrey wrote: If you want to work without a ports tree use pkg_upgrade (sysutils/bsdadminscripts), it only requires an INDEX file. The next version will also require the MOVED file (as is now provided by Pointyhead). Very nice, your program is in the same spirit as my own: http://www.lpthe.jussieu.fr/~talon/pkgupgrade except written in shell, which is quite a feat! Since python is easier to manage, pkgupgrade follows MOVED and tries to be fast. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
Miroslav Lachman wrote: Doug Barton wrote: Michel Talon wrote: Miroslav Lachman wrote: I take a quick look at the code and I have one question. Can you explain way --no-deps and --force are used for pkg_add? I can only venture an explanation. Once you have computed a good order for upgrading via packages, you cannot accept that pkg_add ruins your computation by doing things on its own. In principle you have a global view of the problem, which is better than the local view embedded in each package. Hence forcing pkg_add is the only sane way. Very elegantly stated. :) This is all subject to change of course based on refinement from experience, but this usage matches the way that ports are installed in the well-traveled port building code. Does it mean that one needs ports tree or provide custom INDEX in case of custom packages with non default options (different dependencies) to compute order od dependencies? (AFAIK plain pkg_add works without ports tree and INDEX, that's why I am asking) If you want to work without a ports tree use pkg_upgrade (sysutils/bsdadminscripts), it only requires an INDEX file. The next version will also require the MOVED file (as is now provided by Pointyhead). Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
Doug Barton wrote: Michel Talon wrote: Miroslav Lachman wrote: I take a quick look at the code and I have one question. Can you explain way --no-deps and --force are used for pkg_add? I can only venture an explanation. Once you have computed a good order for upgrading via packages, you cannot accept that pkg_add ruins your computation by doing things on its own. In principle you have a global view of the problem, which is better than the local view embedded in each package. Hence forcing pkg_add is the only sane way. Very elegantly stated. :) This is all subject to change of course based on refinement from experience, but this usage matches the way that ports are installed in the well-traveled port building code. Does it mean that one needs ports tree or provide custom INDEX in case of custom packages with non default options (different dependencies) to compute order od dependencies? (AFAIK plain pkg_add works without ports tree and INDEX, that's why I am asking) It is related to my idea of extending packages with more metadata, for example OS version + arch, used build options (WITH_ / WITHOUT_ etc.) so one can easily determine how this package was built. But it seems as not so easy task to me, as I don't know how to get all the options (from /etc/make.conf, environment variables, /var/db/ports, commandline...) and record them to file in useful way. It can be useful in case where I have some backup of packages from many machines, but have not the original environment, where packages were built etc. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
On Mon, Nov 09, 2009 at 12:05:45PM +0100, Miroslav Lachman wrote: Does it mean that one needs ports tree or provide custom INDEX in case of custom packages with non default options (different dependencies) to compute order od dependencies? (AFAIK plain pkg_add works without ports tree and INDEX, that's why I am asking) This is because a package contains a list of requirements. However problems may appear, for example if requirements have changed between the installation of the ports you have on your machine and the moment when the package has been compiled. Moreover some ports compile different stuff according to what is present on your machine. The configure script may autodetect stuff like gnome, etc. and automatically compile for example a gnome version of the program. For all these reasons there may be divergences between the dependencies as seen on your machine and the ones recorded in the package which has been compiled elsewhere. It is related to my idea of extending packages with more metadata, for example OS version + arch, used build options (WITH_ / WITHOUT_ etc.) so one can easily determine how this package was built. But it seems as not so easy task to me, as I don't know how to get all the options (from /etc/make.conf, environment variables, /var/db/ports, commandline...) and record them to file in useful way. It can be useful in case where I have some backup of packages from many machines, but have not the original environment, where packages were built etc. For the above reasons i think that using precompiled packages should be restricted to people who don't mess with the standard settings. When you install some Debian packages you take them as is, and things generally work because mostly everybody use the same packages which are well tested and coherent. If, on your machine, you want to use a specially configured program, you download the sources and compile it. But you take care yourself of the upgrades of this program. I think that a similar behaviour should be viable on FreeBSD. If you extensively modify the configuration of a large number of ports, you cannot expect a packages-based upgrade to work. In this case the only reasonable way is to upgrade from source. Miroslav Lachman -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
On Mon, Nov 09, 2009 at 02:21:06PM +0100, Michel Talon wrote: ... For the above reasons i think that using precompiled packages should be restricted to people who don't mess with the standard settings. When you install some Debian packages you take them as is, and things generally work because mostly everybody use the same packages which are well tested and coherent. If, on your machine, you want to use a specially configured program, you download the sources and compile it. But you take care yourself of the upgrades of this program. I think that a similar behaviour should be viable on FreeBSD. If you extensively modify the configuration of a large number of ports, you cannot expect a packages-based upgrade to work. In this case the only reasonable way is to upgrade from source. ... In fairness, while I believe that the above analysis is reasonable if one confines the packages in question to those built outside the control of the one changing configurations, one of the reasons I have been interested in package support for portmaster is precisely so I could build packages of ports that I had configured for my environment, then merely install (vs. build) them on other (target) machines. Rebuilding (say) firefox3 on each machine where I want that configuration of firefox3 seems ... rather less than ideal. :-} I should be able to build the ports as I choose to configure them, create packages, and install those packages on the various target machines. Later, when the port gets updated, I'd want to use portmaster to update the port on one machine, build a package for it, then on other machines, use my package to update the port on other machines when I run portmaster on those machines. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp70DlOjsbJI.pgp Description: PGP signature
Re: Portmaster with package support ready for beta testing
Michel Talon wrote: On Mon, Nov 09, 2009 at 12:05:45PM +0100, Miroslav Lachman wrote: [...] For the above reasons i think that using precompiled packages should be restricted to people who don't mess with the standard settings. When you install some Debian packages you take them as is, and things generally work because mostly everybody use the same packages which are well tested and coherent. If, on your machine, you want to use a specially configured program, you download the sources and compile it. But you take care yourself of the upgrades of this program. I think that a similar behaviour should be viable on FreeBSD. If you extensively modify the configuration of a large number of ports, you cannot expect a packages-based upgrade to work. In this case the only reasonable way is to upgrade from source. There are more than one scenario why people may use packages. I am sure many people are using portmaster or portupgrade with auto creation of packages for backup purpose - if I install newer version I need a backup of old package with dependencies for the case where newer version doesn't work well and needs to be rolled back. Similar to when I have more machines and want few of them used as building and testing environment, then deploy packages to production machines. So the extended metadata for packages will be useful for staff, debuging, recovery etc. I am fine with source upgrade for this moment, but source upgrade causes long downtime of services in some cases - longer than upgrade based on packages. And as number of maintained servers grows it will becomes more important. This is why I am interrested in better support of custom built packages for easier upgrade and I am not saying anything bad on current state of packages support in portmaster. It is definitely step forward. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
Miroslav Lachman wrote: Does it mean that one needs ports tree or provide custom INDEX in case of custom packages with non default options (different dependencies) to compute order od dependencies? The INDEX file is not involved at all. Portmaster still uses the ports tree only to determine dependencies. This actually leads to the ability to set different dependencies from the default while still using packages, although for the moment I have it set up so that if you use one of the --packages options it implies -G (no config run) since I'm not 100% sure that using dependencies different from how the packages were built will work in all cases. (AFAIK plain pkg_add works without ports tree and INDEX, that's why I am asking) AFAIK you're correct. However plain pkg_add is a plain installation tool, it's not an upgrade/management tool. In order to determine whether something needs to be upgraded you have to have a frame of reference. :) One of the items on my funding proposal is to incorporate support for the INDEX file into portmaster, although no one has specifically chosen that as a feature to support yet (while several have specifically requested package support). My plan once the package code is done is to add up the General contributions that haven't been allotted to the work on package support and go back up the list of features, including INDEX support. It is related to my idea of extending packages with more metadata, for example OS version + arch, used build options (WITH_ / WITHOUT_ etc.) so one can easily determine how this package was built. I agree that this would be useful. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=106483 which portmaster is doing currently in its own code. But it seems as not so easy task to me, as I don't know how to get all the options (from /etc/make.conf, environment variables, /var/db/ports, commandline...) and record them to file in useful way. Well some of those things that you mentioned have fairly straightforward solutions, but I agree that the not-directly-ports-related stuff (like make.conf) would be harder. Good luck with that. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing!
On 2009-Nov-08 12:56:52 -0800, Doug Barton do...@freebsd.org wrote:
I'm very pleased to announce that the first version of portmaster with
package support is ready for beta testing. :)
Thank you for your efforts.
support next. I don't think ftp support is going to be possible unless
I can find a creative way to download a remote directory list.
This is possible using only base system tools:
aspire% echo dir | ftp ftp://ftp.freebsd.org/pub/FreeBSD/
Trying 204.152.184.73...
Connected to ftp.freebsd.org.
220 Welcome to freebsd.isc.org.
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Switching to Binary mode.
250 Directory successfully changed.
250-If you're looking for one of the FreeBSD releases, please look in the
250-releases/${ARCH}/${RELNAME} directory, where ARCH = alpha, amd64,
250-i386, ia64, pc98, or sparc64 and RELNAME = the release
250-you're interested in, e.g. 6.1-RELEASE or 5.5-RELEASE.
250-
250 Directory successfully changed.
227 Entering Passive Mode (204,152,184,73,225,24).
150 Here comes the directory listing.
drwxrwxr-x6 110 1002 512 Jan 22 2009 CERT
lrwxrwx--x1 110 1002 15 Oct 23 2006 CTM - development/CTM
lrwxrwx--x1 110 1002 17 Oct 23 2006 CVSup -
development/CVSup
drwxrwxr-x4 110 1002 512 Oct 23 2006 ERRATA
lrwxrwx--x1 110 1002 17 Oct 23 2006 FreeBSD-current -
branches/-current
lrwxrwx--x1 110 1002 19 Oct 23 2006 FreeBSD-stable -
branches/4.0-stable
lrwxrwx--x1 110 1002 25 Oct 23 2006 ISO-IMAGES-alpha -
releases/alpha/ISO-IMAGES
lrwxrwx--x1 110 1002 25 Oct 23 2006 ISO-IMAGES-amd64 -
releases/amd64/ISO-IMAGES
...
--
Peter Jeremy
pgp4uNQsv6GUg.pgp
Description: PGP signature
Portmaster with package support ready for beta testing!
Howdy! I'm very pleased to announce that the first version of portmaster with package support is ready for beta testing. :) I'd like to thank all those who have been so generous in supporting this work. It's really a great feeling not only knowing that the community is supportive of my efforts, but also to be able to finally make this feature available after so many requests have been made for it. As you can see from the commit message below I have tried to stay (mostly) command-line compatible with portupgrade so the syntax of the new features shouldn't be a problem. For now the only available method of fetching packages is via http, I'll be working on file system support next. I don't think ftp support is going to be possible unless I can find a creative way to download a remote directory list. *** I'm sure that there are some rough edges, so if you choose to test this please back up at least your /var/db/pkg directory first. *** Things to look out for: 1. If you get a failure on not being able to find a package repository please send me the output of 'uname -r' 2. You should probably use -v to start with (if you don't already) to get an idea of what's happening behind the scenes Things I need testing for: 1. Especially if you set PACKAGESITE, I need to know how people use this, do you keep all your files in one big directory, do you keep them organized by ports category (e.g., archivers, dns, etc.)? 2. If you set the PACKAGEROOT environment variable 3. Interaction of the package stuff with exotic command line options. I've tried to test as many combinations as I can think of, but y'all are more creative than I am. :) If you're reporting a bug or problem please include the output of 'uname -r', what command line options you used, what you thought should happen, what actually happened, any error messages, etc. To get the new version: 1. If you have svn installed: svn co svn://svn.freebsd.org/base/user/dougb/portmaster 2. Via http: http://svn.freebsd.org/viewvc/base/user/dougb/portmaster Enjoy! Doug Original Message Subject: svn commit: r199056 - user/dougb/portmaster Date: Sun, 8 Nov 2009 20:17:15 + (UTC) To: src-committ...@freebsd.org, svn-src-u...@freebsd.org Author: dougb Date: Sun Nov 8 20:17:15 2009 New Revision: 199056 URL: http://svn.freebsd.org/changeset/base/199056 Log: First run at package support! This version is functional and fairly well tested but I'm sure there are bugs and things that don't work as expected Supports the following new options: -P|--packages and -PP|--packages-only ala portupgrade --packages-if-newer This feature will allow package installation if the available package is newer than the installed version, even if it's not the latest version according to your ports tree. [1] Still to come: Support for packages on filesystem, instead of http [1] Special funding committment for this feature and package support generally by: Modirum MDpay Sponsored by: http://dougbarton.us/portmaster-proposal.html Funded by:Christer Solskogen Funded by:Douglas Berry Funded by:Beat Gatzi -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Portmaster with package support ready for beta testing
Miroslav Lachman wrote: I take a quick look at the code and I have one question. Can you explain way --no-deps and --force are used for pkg_add? I can only venture an explanation. Once you have computed a good order for upgrading via packages, you cannot accept that pkg_add ruins your computation by doing things on its own. In principle you have a global view of the problem, which is better than the local view embedded in each package. Hence forcing pkg_add is the only sane way. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
