Re: PLIST=pkg-plist
Quoting Anatoly Borodin [EMAIL PROTECTED] (from Wed, 19 Mar 2008 16:42:19 +0200): Hi! On Wed, Mar 19, 2008 at 1:13 PM, Alexander Leidinger [EMAIL PROTECTED] wrote: Then reinstall a port which exhibits the behavior and search for the line with PLIST TEST (and the line which follows). Just have forgotten: # less /var/db/pkg/linux_base-fc6-6_5/+CONTENTS @comment PKG_FORMAT_REVISION:1.1 @name linux_base-fc6-6_5 @comment ORIGIN:emulators/linux_base-fc6 @cwd /compat/linux @conflicts linux_base-gentoo* @conflicts linux_base-fc4 Can you please try this without your settings in make.conf (empty make.conf, or at least the smallest possible make.conf you can use)? Bye, Alexander. -- All Finagle Laws may be bypassed by learning the simple art of doing without thinking. http://www.Leidinger.netAlexander @ 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: FreeBSD Port: x11/xautolock
On Thu, 20 Mar 2008 00:42:33 +0100 Pietro Cerutti [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Stefan Thurner wrote: | On Wed, Mar 19, 2008 at 11:43:06PM +0100, Pietro Cerutti wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA512 | | Stefan Thurner wrote: | | Hi! | | | | xlockmore ist not a real run dependency. It's just an option as a | | possible locker program. | | nope, it's the default locker. Removing the dependency on it would mean | provide a list of option allowing to choose among the whole set of | available lockers. | And since a locker is just a program being executed upon timeout, | anything could be a locker. | | Ok. But an option to just disable xlockmore would be nice. xlock comes with xlockmore on FreeBSD. It would mean disable a default. You could use OPTIONS to let the user set RUN_DEPENDS and patch the config file (or whatever, I'm not familiar with xautolock) to use what user chooses. If you don't want to do that then yes, you are right, don't remove the dependency as this will break xautolock. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - [EMAIL PROTECTED], PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: PLIST=pkg-plist
Hi! On Thu, Mar 20, 2008 at 8:36 AM, Alexander Leidinger [EMAIL PROTECTED] wrote: # less /var/db/pkg/linux_base-fc6-6_5/+CONTENTS @comment PKG_FORMAT_REVISION:1.1 @name linux_base-fc6-6_5 @comment ORIGIN:emulators/linux_base-fc6 @cwd /compat/linux @conflicts linux_base-gentoo* @conflicts linux_base-fc4 Can you please try this without your settings in make.conf (empty make.conf, or at least the smallest possible make.conf you can use)? 1) empty make.conf - good file 2) -- Mit freundlichen Grüßen, Anatoly Borodin business: [EMAIL PROTECTED] privat: [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: Utility for safe updating of ports in base system
On Thu, 20 Mar 2008, Michel Talon wrote: Doug Barton wrote: So, I renew my inquiry. :) Is portmaster a suitable candidate to fulfill the role of the utility described, and if not, why not? At the risk of being flamed, I certainly hope not. :) i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and consequently that portmaster is not a suitable candidate. That ability is not included in the current requirements document, and was not specifically mentioned the last time we had the discussion on the list. If the portmgr folks intend that to be a requirement, the current ideas list entry should be amended. For example pkg_add installs a binary package, if you want to compile and install you run make all install clean in the ports tree. Um, you lost me there. One of the requirements of an upgrade system is predictability, this can only be achieved by using binary packages. You gain a certain amount of flexibility with packages, at the expense of being able to customize things. As long as the user understands that, then it's fine. Another requirement, in my opinion, is speed, and the lack of speed, which is completely hidden when you compile your packages will be immediately apparent if you try to use packages. Indeed portupgrade has options -P and -PP to work with packages which could serve as a prototype for a pkg_upgrade written in C, except that they work poorly, and in particular run slowly. Where do you think the slowness is? In my opinion, an example of a correct pkg_upgrade type programm written in C++ is the Debian apt-get. It works predictably, fast, etc. One of its features, that i consider very important for correct operation, is that it computes the list of all packages to be deleted and all packages to be installed and asks the user if he agrees before doing anything. Why do you consider this an important feature? (I'm not disagreeing, just curious about your thought process here.) It fetches all necessary packages before installing or deleting anything. That seems sensible, thanks for mentioning that bit. Hence you can be sure that the upgrade process will not end in a mess if something crashes in the middle, like it is the case with all present standard FreeBSD upgraders. Not sure if this helps the situation you're referring to or not, but portmaster will by default make a backup package of each port that it updates, so if something dies in the middle you could back out of it by hand if you need to. Now all that said, I'd love to see us move to a much more robust package management system, or even just a better interface to the one we have. The problem is that I don't have the time to do that as a volunteer project, and I don't think anyone else does either. :) 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]
Re: PLIST=pkg-plist
Hi! On Thu, Mar 20, 2008 at 8:36 AM, Alexander Leidinger [EMAIL PROTECTED] wrote: # less /var/db/pkg/linux_base-fc6-6_5/+CONTENTS @comment PKG_FORMAT_REVISION:1.1 @name linux_base-fc6-6_5 @comment ORIGIN:emulators/linux_base-fc6 @cwd /compat/linux @conflicts linux_base-gentoo* @conflicts linux_base-fc4 Can you please try this without your settings in make.conf (empty make.conf, or at least the smallest possible make.conf you can use)? Hmmm... I experimented with different file contents, and sometimes it goes good, sometimes bad. I cannot see any pattern yet. -- Mit freundlichen Grüßen, Anatoly Borodin business: [EMAIL PROTECTED] privat: [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: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 01:05:27AM -0700, Doug Barton wrote: On Thu, 20 Mar 2008, Michel Talon wrote: Doug Barton wrote: i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and consequently that portmaster is not a suitable candidate. That ability is not included in the current requirements document, and was not specifically mentioned the last time we had the discussion on the list. If the portmgr folks intend that to be a requirement, the current ideas list entry should be amended. Indeed you are right, but i think this should be a requirement for the reasons discussed below, and is implicit in the fact that the projects refers to a portupgrade written in C, and portupgrade has such a feature. For example pkg_add installs a binary package, if you want to compile and install you run make all install clean in the ports tree. Um, you lost me there. This is simple, all pkg_* tools operate on binary packages at present, it would be strange that a newcomer, pkg_upgrade has no way to operate on binary packages. One of the requirements of an upgrade system is predictability, this can only be achieved by using binary packages. You gain a certain amount of flexibility with packages, at the expense of being able to customize things. As long as the user understands that, then it's fine. I agree that the possibility of compiling from source brings ability to costumize things. However this very ability ruins all hope of having a smooth upgrade system. Due to customization, as soon as you have many ports installed, there is a combinatorial explosion of possibilities and nobody can test that the upgrade process works. OpenBSD people have been converted to this idea, and now push for an upgrade from binary packages exclusively. So i think that the user should have two possibilities: - either he wants to customize, and he is on his own. He will need to compile his software, and in this case portmaster is the perfect tool for managing his upgrades. Since the compilation will take most of the time, it is not relevant to consider performance questions on the portmaster side. - or he wants to use a tried and true upgrade path, he doesn't want to spend time compiling, he wants speed. Basically he wants the Debian or Ubuntu experience. In this case, using prebuilt binary packages is the only reasonable way of achieving the result. I agree that due to licence peculiarities (think e.g. Java) there are a small number of ports which will need compilation, so the experience cannot be perfect. Another requirement, in my opinion, is speed, and the lack of speed, which is completely hidden when you compile your packages will be immediately apparent if you try to use packages. Indeed portupgrade has options -P and -PP to work with packages which could serve as a prototype for a pkg_upgrade written in C, except that they work poorly, and in particular run slowly. Where do you think the slowness is? Several causes of slowness have already been identified. Parsing /var/db/pkg is slow, this is why the idea of using a database has been advocated. Much worse, running make in a port directory, even only to get the value of a variable is slow. Programs like portupgrade do such things repeatedly without caching the results in memory and incur large time penalties. Similarly for each package he wants to download, portupgrade opens an ftp connection and retreives it independently, etc. Obviously no effort at all has been spent so that things are fast. One of its features, that i consider very important for correct operation, is that it computes the list of all packages to be deleted and all packages to be installed and asks the user if he agrees before doing anything. Why do you consider this an important feature? (I'm not disagreeing, just curious about your thought process here.) Because you can see that something is going to break in advance and renounce to the upgrade. This occurred several times for me on Debian. Usually this is because some package has a security problem, and this is solved waiting one or two days. It fetches all necessary packages before installing or deleting anything. That seems sensible, thanks for mentioning that bit. Hence you can be sure that the upgrade process will not end in a mess if something crashes in the middle, like it is the case with all present standard FreeBSD upgraders. Not sure if this helps the situation you're referring to or not, but portmaster will by default make a backup package of each port that it updates, so if something dies in the middle you could back out of it by hand if you need to. Yes, so does portupgrade, but it deletes the backup as soon as the installation of the new port succeeds. This means that in the event of a crash in the middle you remain with a half upgraded system, and no way to backup completely to the previous working state.
Two Years interest free on Whitsunday apartment
Dear , You have just received a message from Steve Marks at Ray White Whitsunday. To view your message, please visit the following address: http://campaign.raywhite.com/ve/ZZP7058X319982X6585w87 To unsubscribe, reply to this email and change the subject to be: unsubscribe If you have trouble viewing this message please see below for detailed instructions. If your e-mail program does not allow you to click directly on the above address (such as AOL), you will need to copy and paste the address into your World Wide Web browser (eg Netscape Navigator or Internet Explorer). Follow the directions below for the simplest way to pick up your message. 1. Make sure you only have one web browser open. 2. Highlight the address by dragging the cursor across the URL (make sure you get the whole address). 3. Copy and paste the URL into your web browser. 4. Press 'enter'. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
Michel Talon [EMAIL PROTECTED] writes: Doug Barton wrote: So, I renew my inquiry. :) Is portmaster a suitable candidate to fulfill the role of the utility described, and if not, why not? At the risk of being flamed, i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and I think this should be the main usage of a possible `pkg_upgrade', just like `pkg_add -u' in OpenBSD. If one is going to install/upgrade packages without a ports tree in the system, `pkg_upgrade' should be able do all the dependency checkings, downloadings and installings/upgradings. consequently that portmaster is not a suitable candidate. For example pkg_add installs a binary package, if you want to compile and install you run make all install clean in the ports tree. One of the requirements of an upgrade system is predictability, this can only be achieved by using binary packages. Another requirement, in my opinion, is speed, and the lack of speed, which is completely hidden when you compile your packages will be immediately apparent if you try to use packages. Indeed portupgrade has options -P and -PP to work with packages which could serve as a prototype for a pkg_upgrade written in C, except that they work poorly, and in particular run slowly. The most inconvenient is that `portupgrade' depends on ruby to run, which makes it a little bit, maybe, annoying. In my opinion, an example of a correct pkg_upgrade type programm written in C++ is the Debian apt-get. It works predictably, fast, etc. One of its features, that i consider very important for correct operation, is that it computes the list of all packages to be deleted and all packages to be installed and asks the user if he agrees before Yes, I think you are right. The new `pkg_upgrade' should be able to report the unavailability of a package and do a graceful exit. doing anything. It fetches all necessary packages before installing or deleting anything. Hence you can be sure that the upgrade process will not end in a mess if something crashes in the middle, like it is the case with all present standard FreeBSD upgraders. Actually I don't think a batch download and install process would help much, especially for a freshly installed system because it might be a huge download job and much waiting time if one is going to install GNOME/KDE etc. from scratch. Perhaps the new `pkg_upgrade' could provide versatile options to complete such tasks. -- Denise H. G. darcsis AT gmail DOT com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: updating devel/directfb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Anatoly Borodin wrote: | Thank you for this patch, but I need 1.1.1 version (I use some | features released here), so I merged you patch with mine. The result | is http://fractalizator.googlepages.com/directfb-0.9.16-1.1.1.patch.txt Hi back, the patch is ok. It only has a plist problem when neither WITH_X11= nor WITH_SDL= is set: pkg_delete: file '/usr/local/lib/directfb-1.1-0/inputdrivers' doesn't exist pkg_delete: unable to completely remove directory '/usr/local/lib/directfb-1.1-0/inputdrivers' Could you quickly look at it? - -- Pietro Cerutti [EMAIL PROTECTED] PGP Public Key: http://gahr.ch/pgp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (FreeBSD) iEYEAREKAAYFAkfiQQAACgkQwMJqmJVx9454oQCfa0bVQPRlCu321mqEp3lJmNNZ nggAoJocgvaonlHAtzLi2DS2K2USrqRy =cXp9 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: updating devel/directfb
Hi! On Thu, Mar 20, 2008 at 12:48 PM, Pietro Cerutti [EMAIL PROTECTED] wrote: | Thank you for this patch, but I need 1.1.1 version (I use some | features released here), so I merged you patch with mine. The result | is http://fractalizator.googlepages.com/directfb-0.9.16-1.1.1.patch.txt Hi back, the patch is ok. It only has a plist problem when neither WITH_X11= nor WITH_SDL= is set: pkg_delete: file '/usr/local/lib/directfb-1.1-0/inputdrivers' doesn't exist pkg_delete: unable to completely remove directory '/usr/local/lib/directfb-1.1-0/inputdrivers' Could you quickly look at it? The patch is corrected. -- Mit freundlichen Grüßen, Anatoly Borodin business: [EMAIL PROTECTED] privat: [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: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 01:05:27AM -0700, Doug Barton wrote: ... One of the requirements of an upgrade system is predictability, this can only be achieved by using binary packages. You gain a certain amount of flexibility with packages, at the expense of being able to customize things. As long as the user understands that, then it's fine. ... With respect, that (the notion that use of packages inherently reduces flexibility) doesn't quite follow, from my perspective: it depends on who makes the packages. (What follows is unlikely new to Doug, as I touched on it a while back in a private exchange; I thought it might be of use or interest to the list, though.) My preferred MO is to build from sources, but within a given set of related machines (of sufficiently similar architectures), avoid doing the builds themselves on production machines: I have a machine set up to do FreeBSD builds, for example, and install FreeBSD, built on that system, onto other system(s) here at home. That is why the output of uname -a on my firewall machine (janus) shows that the kernel was actually built on a machine named freebeast: janus(6.3-S)[1] uname -a FreeBSD janus.catwhisker.org 6.3-STABLE FreeBSD 6.3-STABLE #24: Sun Mar 2 07:13:33 PST 2008 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/JANUS i386 janus(6.3-S)[2] I would prefer to do something similar for ports: build my own packages on that machine, then be able to use my preferred port management tool to run through the list of installed ports on (say) my firewall box, and have it fetch the packages from my local machine (or effectively *on* the machine being updated, as my build machine exports certain file systems to facilitate installation on other local machines). (And this is, in fact, how I had things set up when I used a different port management program.) This also allows me to have built a package on the non-production build machine, test it, and after I'm satisfied that the package is likely to work in my environment, upgrade the port on a somewhat more sensitive machine (e.g., the one my spouse uses for email Web browsing). And there are some ports -- OpenOffice and Firefox come to mind -- where building a given version more than once veers into the masochistic classification (IMO). (And in the case of OpenOffice, in particular, the port might feasibly be installed and used on a system that doesn't really have the resources to build it.) Thus, for me, being able to customize by building my own packages, then using those custom-built packages for upgrading other systems is a useful approach. While in theory, I could do this manually (roughly: run the port management tool with a -n flag so it won't actually change anything, but would report what warrants updating, then, for each port that has an available update, force a pkg_delete, then do a pkg_add using the updated port's package), that's a lot of clerical work to do by hand -- and to me, that's just about synonymous with error-prone. So having my preferred port management tool be able to perfom upgrades using packages would be useful for me. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that conspiracy would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp6J0oy7TCxz.pgp Description: PGP signature
libnjb pkg-plist incorrect?
%%PORTDOCS%%share/doc/libnjb-%%PORTVERSION%%/html/dir_d03f56ed3ef2c0e11ac283c787a57d7a.html is in pkg-plist of libnjb, but I got this file: dir_517a6f2c7427bc36231829858e370602.html Therefore package creation fails. Does this weird filename have something to do with my configuration? Is pkg-plist incorrect? Jan Henrik ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
The real question is: ports or packages? Please do not mix them together! If we are talking about ports and ports updating then portmaster is (now) an excellent candidate for this job and I vote for portmaster. If we are talking about packages and package management then portmaster and all other ports updating tools are of course out of context. They are ports management tools - not - package management tools. So please change http://www.freebsd.org/projects/ideas/index.html#p-ports-upgrade The project idea is called 'Utility for safe updating of ports in base system'. The jobs description is false because of using 'pkg_*' but meaning 'port*'. And it really looks just like a request for rewrite portupgrade in C and to put this rewritten portupgrade in base. I strongly vote against it! The entry 'Package tools improvements' http://www.freebsd.org/projects/ideas/index.html#p-ports-pkgtools should be extended / rewritten for a new package management tool (/framework) idea. Michel Talon had described such a tool. So we are actually talking about two different things ... -- Regards, Sticky Bit [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: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 05:59:28PM +0800, Denise H. G. wrote: Michel Talon [EMAIL PROTECTED] writes: Actually I don't think a batch download and install process would help much, especially for a freshly installed system because it might be a huge download job and much waiting time if one is going to install GNOME/KDE etc. from scratch. Perhaps the new `pkg_upgrade' could provide versatile options to complete such tasks. In fact a batch download, followed by batch install is much faster than constant interspersing of backup, download, install, etc. like portupgrade does. In particular there is only one ftp connection for downloading everything which cuts on time, and you can do backups at the same time. If you don't beleive me you can try the prototype (in python) that i have written a year ago, and which does precisely that: http://www.lpthe.jussieu.fr/~talon/pkgupgrade (which needs http://www.lpthe.jussieu.fr/~talon/pkg_save.py) Most of the time in the script is spent recomputing the INDEX for all installed files, because i assumed the INDEX is not necessarily up to date. -- Denise H. G. darcsis AT gmail DOT com -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libnjb pkg-plist incorrect?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jan Henrik Sylvester wrote: | %%PORTDOCS%%share/doc/libnjb-%%PORTVERSION%%/html/dir_d03f56ed3ef2c0e11ac283c787a57d7a.html | | is in pkg-plist of libnjb, but I got this file: | dir_517a6f2c7427bc36231829858e370602.html | | Therefore package creation fails. :-) it's my fault... stay tuned for a correction within minutes! Thanks for pointing it out! ~ Jan Henrik - -- Pietro Cerutti [EMAIL PROTECTED] PGP Public Key: http://gahr.ch/pgp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (FreeBSD) iEYEAREKAAYFAkfmU00ACgkQwMJqmJVx945irACfb1NJLt51bVMMSKIkEeJI9LCE +dwAoLR5Q5nkLt992cyDa698y3VmxLXt =yOp9 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PLIST=pkg-plist
Hi!
On Thu, Mar 20, 2008 at 8:36 AM, Alexander Leidinger
[EMAIL PROTECTED] wrote:
Can you please try this without your settings in make.conf (empty
make.conf, or at least the smallest possible make.conf you can use)?
I've found that make.conf is irrelevant, but some other thing matters
# cat /root/testl.sh
#!/bin/sh
WRKDIRPREFIX=/usr/obj
PORT=/usr/ports/emulators/linux_base-fc6
CONTENTS=/var/db/pkg/linux_base-fc6*/+CONTENTS
P=`pwd`;
LOG=/root/testl.log
echo -n ${LOG}
rm -rf ${WRKDIRPREFIX}${PORT};
echo 'make clean' ${LOG}
for i in 1 2 3 4 5;
do
cd ${PORT};
make clean;
make -DFORCE_PKG_REGISTER WRKDIRPREFIX=${WRKDIRPREFIX} install;
make clean;
cd ${P};
wc -l ${CONTENTS} ${LOG};
done
echo 'rm -rf' $LOG
for i in 1 2 3 4 5;
do
cd ${PORT};
rm -rf ${WRKDIRPREFIX}${PORT};
make -DFORCE_PKG_REGISTER WRKDIRPREFIX=${WRKDIRPREFIX} install;
rm -rf ${WRKDIRPREFIX}${PORT};
cd ${P};
wc -l ${CONTENTS} ${LOG};
done
clear;
less ${LOG};
# sh /root/testl.sh; cat /root/testl.log
make clean
20067 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
6 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
6 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
6 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
6 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
rm -rf
20067 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
20067 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
20067 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
20067 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
20067 /var/db/pkg/linux_base-fc6-6_5/+CONTENTS
--
Mit freundlichen Grüßen,
Anatoly Borodin
business: [EMAIL PROTECTED]
privat: [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: Utility for safe updating of ports in base system
Michel Talon [EMAIL PROTECTED] writes: On Thu, Mar 20, 2008 at 05:59:28PM +0800, Denise H. G. wrote: Michel Talon [EMAIL PROTECTED] writes: Actually I don't think a batch download and install process would help much, especially for a freshly installed system because it might be a huge download job and much waiting time if one is going to install GNOME/KDE etc. from scratch. Perhaps the new `pkg_upgrade' could provide versatile options to complete such tasks. In fact a batch download, followed by batch install is much faster than constant interspersing of backup, download, install, etc. like portupgrade does. In particular there is only one ftp connection for downloading everything which cuts on time, and you can do backups at the Yes, you are right. I just think that people could have options while doing things. This would make the world more satisfying. same time. If you don't beleive me you can try the prototype (in python) that i have written a year ago, and which does precisely that: http://www.lpthe.jussieu.fr/~talon/pkgupgrade (which needs http://www.lpthe.jussieu.fr/~talon/pkg_save.py) Most of the time in the script is spent recomputing the INDEX for all installed files, because i assumed the INDEX is not necessarily up to date. Yes, I've had great impressions by the debian's apt- tools. But it seems that the debian package servers maintain an index or something for all the packages. And if you want to upgrade or install a certain package, you just fetch the meta info for that package from the package server and do a comparison with your local index. This makes versioned dependencies rather easy to play around. -- Denise H. G. darcsis AT gmail DOT com -- Denise H. G. darcsis AT gmail DOT com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: tcl-threads-8.5.1
How come there is a tcl8.4 entry on the sections pull down but no 8.5 entries? Also, is there a ports package for TkThread and Tdom (I'm looking for the same package set that ActiveState has on their supported platforms)? Lastly, any thoughts on a tclkit/basekit for FreeBSD? Thanks in advance! -- ++ | Gerald W. Lester, Director of Technology, TicketSwitch USA LLC | | Office: +1.504.267.3745 Fax: +1.504.342.4168 Cell: +1.504.292.3775 | | Email: [EMAIL PROTECTED] | |The man who fights for his ideals is the man who is alive. - Cervantes| ++ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
portupgrade with -o doesn't apply any make flags
I've noticed that with the current (non-devel) version of portupgrade, when I was doing a replacement with -o specified, none of the make flags from pkgtools.conf were being applied like they normally are when I do a normal upgrade or an install. I haven't had a chance to test portupgrade-devel or not, but has it been fixed in that? Thanks, Naram Qashat ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
unbreak emulators/doscmd
Hi Des, I have a patch to unbreak emulators/doscmd on = 80, would you mind to have a look at it? http://people.freebsd.org/~gahr/doscmd.diff Thanks, Best Regards -- Pietro Cerutti PGP Public Key: http://gahr.ch/pgp signature.asc Description: OpenPGP digital signature
Re: Utility for safe updating of ports in base system
On Thu, 20 Mar 2008, Michel Talon wrote: On Thu, Mar 20, 2008 at 05:59:28PM +0800, Denise H. G. wrote: Michel Talon [EMAIL PROTECTED] writes: Actually I don't think a batch download and install process would help much, especially for a freshly installed system because it might be a huge download job and much waiting time if one is going to install GNOME/KDE etc. from scratch. Perhaps the new `pkg_upgrade' could provide versatile options to complete such tasks. In fact a batch download, followed by batch install is much faster than constant interspersing of backup, download, install, etc. like portupgrade does. In particular there is only one ftp connection for downloading everything which cuts on time, and you can do backups at the same time. If you don't beleive me you can try the prototype (in python) that i have written a year ago, and which does precisely that: http://www.lpthe.jussieu.fr/~talon/pkgupgrade (which needs http://www.lpthe.jussieu.fr/~talon/pkg_save.py) Most of the time in the script is spent recomputing the INDEX for all installed files, because i assumed the INDEX is not necessarily up to date. Except for the package portion, I also wrote a script to update ports[1] when Perl was still in the base. The features I really like about it: 1. No dependency on INDEX. This does make it more expensive to start, but the program does cache as much as possible as it runs. No need to perform a duplicate make all-depends-list in a directory if it has already been performed. 2. Precalculation of updates before starting. This allows a lot of operations to be performed upfront: ignore checking, conflict checking, prefetching and ports no longer needed by child ports. 3. Crash recovery. It saves what it has completed along with the build tree to a database, so recovery/restarts are quick. 4. Uses portconf for settings and its own rc file to determine what not to build. BTW, I think the +IGNOREME files for portmaster should be in /var/db/ports, so they may traverse a manual pkg_delete make install. Cons: 1. I have not put much time into it lately. 2. Perl is not part of base. 3. Does not respect options set in /var/db/ports. It solely relies on portconf. 4. The tree building code is really convoluted and needs replacement. Sean 1. http://www.farley.org/freebsd/#pc -- [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: Utility for safe updating of ports in base system
On Thu, 20 Mar 2008, Doug Barton wrote: On Thu, 20 Mar 2008, Michel Talon wrote: In my opinion, an example of a correct pkg_upgrade type programm written in C++ is the Debian apt-get. It works predictably, fast, etc. One of its features, that i consider very important for correct operation, is that it computes the list of all packages to be deleted and all packages to be installed and asks the user if he agrees before doing anything. Why do you consider this an important feature? (I'm not disagreeing, just curious about your thought process here.) Personally, I like to know everything that will happen before it happens. When options change, I am not always sure what it will bring. For example, I do not have HAL (WITHOUT_HAL via portconf) installed on my system. Some ports may try to bring it in regardless of the setting; I would like to see that first. In this case, I think portmaster -na gives me an idea of what will happen. Sean -- [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: Utility for safe updating of ports in base system
On Thu, 20 Mar 2008 05:23:23 -0700 David Wolfskill wrote: I would prefer to do something similar for ports: build my own packages on that machine, then be able to use my preferred port management tool to run through the list of installed ports on (say) my firewall box, and have it fetch the packages from my local machine The port ports-mgmt/tinderbox does just what you need. WBR -- bsam ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transferring ports
On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote:
* Ivan Voras ([EMAIL PROTECTED]) wrote:
Is there a utility that would do that, and if not, does anyone have the
time to write one?
Actually, I've already had an idea of utility with pretty similar
functionality for a long time. The utility would copy directory
hierarchies recursively based on file include/exclude list, like this:
+/{etc,bin,sbin,lib}
+/usr
-/usr/local
+/usr/local/{bin,sbin,libexec,share,lib}
-/usr/share/locale
+/usr/share/locale/ru_RU*
so `my_cool_copy_utility / /path/to/jail` will copy /etc,/bin,/sbin,/lib
and /usr dirs to jail, but in /usr/share/locale will only copy
russian locales, but no others, and in usr/local it won't copy
man, include and other dirs not needed in a jail.
The purpose is similar - creating jails out of host system in fast
and easy way, possibility to strip everything unneeded (useful for
secure minimal jails or flash/livecd/embedded installations of
minimal size) and add something extra, like stuff from /usr/local
without installing full packages in a jail, or, say, copying over
additional tree of jail-specific changes (mostly stuff under /etc
and /usr/local/etc).
Such an utility is something I still might start working on.
Err... why not use rsync for that? It works locally, too -
I use it to copy directories all over the place all the time.
Come to think of it... oh, just go install net/rsync, take a look at
its manual page and the FILTER RULES section in particular - it even
supports rules with prefixes, - for exclude, + for include, just
like you want them :) Well, okay, you might need to list separate
directories on separate lines (it doesn't seem to support the {bin,sbin}
syntax), but other than that, it seems to fit your requirements pretty
well :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence claims to be an Epimenides paradox, but it is lying.
pgpvZaprrNwIx.pgp
Description: PGP signature
Re: Transferring ports
Peter Pentchev wrote: On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: * Ivan Voras ([EMAIL PROTECTED]) wrote: Is there a utility that would do that, and if not, does anyone have the time to write one? Would this not be an appropriate use for packages? If one creates a package for every installed port on the host system, then one simply installs the package on the target system. I have used this technique with some success when transferring ports from one system to another. In my situation, I'm using the same architecture (i386) and OS version (6.3 -- 6.3 or 7.0 -- 7.0). -- Regards, Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 09:34:38PM +0800, Denise H. G. wrote: Yes, I've had great impressions by the debian's apt- tools. But it seems that the debian package servers maintain an index or something for all the packages. And if you want to upgrade or install a certain package, you just fetch the meta info for that package from the package server and do a comparison with your local index. This makes versioned dependencies rather easy to play around. Indeed there is a compressed file on the Debian repository, containing all information on each available package. It is stored locally by apt-get when you run apt-get update in a custom database. Similarly apt-get maintains information in the database of the installed packages. Hence comparison is easy and fast. In the FreeBSD case there is always an INDEX file in the FreeBSD repositories which lists similar information (perhaps not enough information) for each package. So in principle one could do similar things as Debian does. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transferring ports
On 20/03/2008, Doug Poland [EMAIL PROTECTED] wrote: Peter Pentchev wrote: On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: * Ivan Voras ([EMAIL PROTECTED]) wrote: Is there a utility that would do that, and if not, does anyone have the time to write one? Would this not be an appropriate use for packages? If one creates a package for every installed port on the host system, then one simply installs the package on the target system. Yes, that's exactly what I need (the same functionality as pkg_create -b + install on the other system), only without the actual package file being created. Pipes would also be acceptable (piping the output of pkg_create from one machine to the other, etc). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transferring ports
Peter Pentchev wrote: On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: The purpose is similar - creating jails out of host system in fast and easy way, possibility to strip everything unneeded (useful for secure minimal jails or flash/livecd/embedded installations of minimal size) and add something extra, like stuff from /usr/local without installing full packages in a jail, or, say, copying over additional tree of jail-specific changes (mostly stuff under /etc and /usr/local/etc). Such an utility is something I still might start working on. I don't use the host system.. I keep a special pristine jail just for that purpose (to act as a source for other jails). sometimes I also use null=mounts, and sometimes if the jails are on one big partition, I hardlink some stuff.. e.g binaries in /bin etc betweem teh jails.. saves memory and disk.. Of course that is only when I basically trust the jail user (me). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
Doug Barton píše v čt 20. 03. 2008 v 01:05 -0700: On Thu, 20 Mar 2008, Michel Talon wrote: i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and consequently that portmaster is not a suitable candidate. That ability is not included in the current requirements document, and was not specifically mentioned the last time we had the discussion on the list. If the portmgr folks intend that to be a requirement, the current ideas list entry should be amended. Yes, I think ability to work with packages on a remote FTP site with no local /usr/ports, solely relying on an INDEX file, is a solid must have requirement. I have added that to the entry in the Ideas page. At the same time, ability to work on a local /usr/ports _without_ INDEX file is also a requirement. I think we should be pushing our packages and package-only modes of operation to the mainstream users. Especially now when we can afford to build a complete package set for all existing platforms/architectures on a 48-hour cycle basis. There should also be an overhaul of current ftp mirrors infrastructure, which might not be able to sustain the constant flow of new packages. Moving over from ftp to http would also eliminate a lot of the latency issues as mentioned elsewhere in this thread. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Your sig line (k) was stolen! -more- There is a puff of smoke! signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: FreeBSD Port: tcl-threads-8.5.1
Gerald W. Lester píše v čt 20. 03. 2008 v 08:43 -0500: How come there is a tcl8.4 entry on the sections pull down but no 8.5 entries? The versioned tcl/tk categories are going away soon. In the new order, everything will be just tcl or tk. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] End users have trouble keeping food off their keyboard and sorting messages in Outlook. Try explaining this problem to them. signature.asc Description: Toto je digitálně podepsaná část zprávy
Installing a shell script
Greetings-
I am in the process of updating a port to the latest version (dns/dnsperf)
and I ran into an issue I was able to work around but I want to see if
there is a nicer way to do it.
One of the differences between the version in ports and the current version
is the addition of a shell script called resperf-report. If I simply use stock
install method, I end up with the following error:
strip: /usr/local/bin/resperf-report: File format not recognized
install: wait: No such file or directory
*** Error code 70
So, to work around this what I ended up doing is basically installing the
binaries and man pages by hand:
-PLIST_FILES= bin/dnsperf bin/resperf
+PLIST_FILES= bin/dnsperf bin/resperf bin/resperf-report
MAN1= dnsperf.1 resperf.1
+do-install:
+ ${INSTALL} ${WRKSRC}/dnsperf ${PREFIX}/bin
+ ${INSTALL} ${WRKSRC}/resperf ${PREFIX}/bin
+ ${INSTALL_SCRIPT} ${WRKSRC}/resperf-report ${PREFIX}/bin
+.for MAN in ${MAN1}
+ ${INSTALL_MAN} ${WRKSRC}/${MAN} ${PREFIX}/man/man1
+.endfor
+
.include bsd.port.mk
Is there a better way to do this? Can I someone
set a flag to tell the stock do-install to not strip the resperf-report
when doing an install?
Thanks
--
Steven Kreuzer
http://www.exit2shell.com/~skreuzer
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing a shell script
On Thu, Mar 20, 2008 at 02:51:45PM -0400, Steven Kreuzer wrote:
Greetings-
I am in the process of updating a port to the latest version (dns/dnsperf)
and I ran into an issue I was able to work around but I want to see if
there is a nicer way to do it.
One of the differences between the version in ports and the current version
is the addition of a shell script called resperf-report. If I simply use stock
install method, I end up with the following error:
strip: /usr/local/bin/resperf-report: File format not recognized
install: wait: No such file or directory
*** Error code 70
So, to work around this what I ended up doing is basically installing the
binaries and man pages by hand:
-PLIST_FILES= bin/dnsperf bin/resperf
+PLIST_FILES= bin/dnsperf bin/resperf bin/resperf-report
MAN1= dnsperf.1 resperf.1
+do-install:
+ ${INSTALL} ${WRKSRC}/dnsperf ${PREFIX}/bin
+ ${INSTALL} ${WRKSRC}/resperf ${PREFIX}/bin
+ ${INSTALL_SCRIPT} ${WRKSRC}/resperf-report ${PREFIX}/bin
+.for MAN in ${MAN1}
+ ${INSTALL_MAN} ${WRKSRC}/${MAN} ${PREFIX}/man/man1
+.endfor
+
.include bsd.port.mk
Is there a better way to do this? Can I someone
set a flag to tell the stock do-install to not strip the resperf-report
when doing an install?
Does setting STRIP to an empty string work? Acorrding to bsd.port.mk it
should.
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
Hi, On Thu, Mar 20, 2008 at 01:05:27AM -0700, Doug Barton wrote: Now all that said, I'd love to see us move to a much more robust package management system, or even just a better interface to the one we have. The problem is that I don't have the time to do that as a volunteer project, and I don't think anyone else does either. :) I did a lot of this work, when I did have the time: http://sourceforge.net/projects/fpkg/ Supports upgrading (doesn't move the files to compat, but that would be a five line change), backups, db files, versioned depends, pkg_which. Just about all of the ideas on that page, but not command line compatible with portupgrade. I haven't played with it in years. It would need all of the pkg_install features and fixes from about 2004 (or maybe earlier) merged in (or reimplemented). Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transferring ports
Ivan Voras wrote: On 20/03/2008, Doug Poland [EMAIL PROTECTED] wrote: Peter Pentchev wrote: On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote: * Ivan Voras ([EMAIL PROTECTED]) wrote: Is there a utility that would do that, and if not, does anyone have the time to write one? Would this not be an appropriate use for packages? If one creates a package for every installed port on the host system, then one simply installs the package on the target system. Yes, that's exactly what I need (the same functionality as pkg_create -b + install on the other system), only without the actual package file being created. Pipes would also be acceptable (piping the output of pkg_create from one machine to the other, etc). Too bad you cannot accept the package file. If pkg_create would accept a - instead of specifying the output tarball, then one could do some foo with nc, i.e., target# nc -l 1234 | tar -xf - source# pkg_create -b mypackage - | nc target 1234 -- Regards, Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
Michel Talon wrote: On Thu, Mar 20, 2008 at 01:05:27AM -0700, Doug Barton wrote: On Thu, 20 Mar 2008, Michel Talon wrote: Doug Barton wrote: i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and consequently that portmaster is not a suitable candidate. That ability is not included in the current requirements document, and was not specifically mentioned the last time we had the discussion on the list. If the portmgr folks intend that to be a requirement, the current ideas list entry should be amended. Indeed you are right, but i think this should be a requirement for the reasons discussed below, and is implicit in the fact that the projects refers to a portupgrade written in C, and portupgrade has such a feature. Implicit requirements suck. :) However pav obviously agrees with you. For example pkg_add installs a binary package, if you want to compile and install you run make all install clean in the ports tree. Um, you lost me there. This is simple, all pkg_* tools operate on binary packages at present, Ok, but that's not compile and install, which is why I wanted to clarify. it would be strange that a newcomer, pkg_upgrade has no way to operate on binary packages. I think reasonable minds could differ on that, but now we know what pav at least thinks. One of the requirements of an upgrade system is predictability, this can only be achieved by using binary packages. You gain a certain amount of flexibility with packages, at the expense of being able to customize things. As long as the user understands that, then it's fine. I agree that the possibility of compiling from source brings ability to costumize things. However this very ability ruins all hope of having a smooth upgrade system. Due to customization, as soon as you have many ports installed, there is a combinatorial explosion of possibilities and nobody can test that the upgrade process works. I agree with what you're saying to a point, however in my experience it's very rare that at least my particular combination of options leads to an explosion, so I'm not really sold on the idea of mandatory binary-only upgrades. OpenBSD people have been converted to this idea, and now push for an upgrade from binary packages exclusively. I think we need to keep the tools not policy mantra in mind here. So i think that the user should have two possibilities: - either he wants to customize, and he is on his own. He will need to compile his software, and in this case portmaster is the perfect tool for managing his upgrades. Thanks. :) Since the compilation will take most of the time, it is not relevant to consider performance questions on the portmaster side. Having spent a substantial amount of time doing performance tuning on portmaster, I beg to differ. You're right of course that for the average port the majority of time is going to be spent in compiling, however if you're going to be doing something like 'portmaster -a' simply caching the results of the up-to-date tests of the lower level dependencies can cut the portmaster time for an upgrade of several ports by more than 1/3rd. And portmaster has a lot of other optimizations as well, such as downloading distfiles in the background, etc. - or he wants to use a tried and true upgrade path, he doesn't want to spend time compiling, he wants speed. Basically he wants the Debian or Ubuntu experience. In this case, using prebuilt binary packages is the only reasonable way of achieving the result. Well, given the overwhelming number of ports, and the lack of resources to do QA on them, I think we should substitute more likely to succeed for tried and true there. That said, I have used Ubuntu for a project I did for a client, and I really liked the package management system. However you're talking orders of magnitude more work (and several redesigns of core elements) before we could get close to the Ubuntu experience. I'm concerned that in the interest of waiting for the perfect thing we do our users a disservice by not taking incremental steps toward the goal. Another requirement, in my opinion, is speed, and the lack of speed, which is completely hidden when you compile your packages will be immediately apparent if you try to use packages. Indeed portupgrade has options -P and -PP to work with packages which could serve as a prototype for a pkg_upgrade written in C, except that they work poorly, and in particular run slowly. Where do you think the slowness is? Several causes of slowness have already been identified. Parsing /var/db/pkg is slow, s/is/can be/. There are some things I need to dig out of /var/db/pkg that are relatively slow, yes. By far the most expensive is determining the name of an installed port by grep'ing for ORIGIN in all the +CONTENTS files. However even that is not overwhelmingly slow. If I do a cold search for the very last installed port on my
Re: Utility for safe updating of ports in base system
Sean C. Farley wrote: BTW, I think the +IGNOREME files for portmaster should be in /var/db/ports, so they may traverse a manual pkg_delete make install. I'm ambivalent about that, since the way I personally tend to use +IGNOREME is to avoid dealing with something till I'm ready to update it, and then I generally want the +IGNOREME file to go away. I would think that at minimum it should look both places. Also, I'm a little more sympathetic to this idea now that portmaster does a better job of letting the user know that there is an +IGNOREME file present at various decision making points. 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]
Re: Utility for safe updating of ports in base system
Pav Lucistnik wrote: Doug Barton píe v c(t 20. 03. 2008 v 01:05 -0700: On Thu, 20 Mar 2008, Michel Talon wrote: i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and consequently that portmaster is not a suitable candidate. That ability is not included in the current requirements document, and was not specifically mentioned the last time we had the discussion on the list. If the portmgr folks intend that to be a requirement, the current ideas list entry should be amended. Yes, I think ability to work with packages on a remote FTP site with no local /usr/ports, solely relying on an INDEX file, is a solid must have requirement. I have added that to the entry in the Ideas page. Fair enough, but can we please come quickly to a consensus on what _all_ of the requirements should be? Two things I'd like to avoid. One is the feeling that no matter how many hoops I jump through, there is always going to be one more placed in my path because we really don't want portmaster in the base. The other is frustration on the part of any student brave enough to tackle this task. At the same time, ability to work on a local /usr/ports _without_ INDEX file is also a requirement. That should be mentioned then, but the good news is that portmaster already fulfills that one. It never uses the INDEX file for anything. I think we should be pushing our packages and package-only modes of operation to the mainstream users. Especially now when we can afford to build a complete package set for all existing platforms/architectures on a 48-hour cycle basis. I would be more sympathetic to this idea if we could somehow push security-sensitive package builds up to the top of the list (so they would be available ASAP), but the last time I inquired about this I was told it isn't possible. There should also be an overhaul of current ftp mirrors infrastructure, which might not be able to sustain the constant flow of new packages. You also need to look at the other side of that, which is an exponential increase in the number of package downloads, and the incumbent costs in terms of bandwidth, processor time, etc. 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]
Re: Utility for safe updating of ports in base system
On Thu, Mar 20, 2008 at 01:12:06PM -0700, Doug Barton wrote: Fair enough, but can we please come quickly to a consensus on what _all_ of the requirements should be? Two things I'd like to avoid. One is the feeling that no matter how many hoops I jump through, there is always going to be one more placed in my path because we really don't want portmaster in the base. The other is frustration on the part of any student brave enough to tackle this task. Now that it is clear that 2 different things are desirable, a utility to upgrade by ports, and a utility to upgrade by packages, may i say that i agree completely that portmaster does the first perfectly, and should be in the base system, notably since it is a shell script which doesn't cost anything. But i remain convinced that the second one is also necessary and in fact much more important. Since portmaster is already here, a SOC project should concentrate on the second aim, which is perfectly summarized by the name pkg_upgrade (by opposition to port_upgrade). The ideas necessary to develop such a project are apparent in the ruby program portupgrade and/or my python pkgupgrade, but a C program is desirable so that there is no external dependency. More precisely portupgrade and pkgupgrade both use extensively data structures such as arrays and dictionaries (perl hashes) so it may be that using C++ and the STL containers is more convenient than C. You also need to look at the other side of that, which is an exponential increase in the number of package downloads, and the incumbent costs in terms of bandwidth, processor time, etc. All big Linux distributions, which have many times more users, incur this cost without apparent problem. For example my provider, which is a quite large one, has a mirror of many distributions, including Free and NetBSD, with incredible bandwith. See ftp://ftp.free.fr/mirrors I can download a DVD from my office at 100Mb/s from here at any time. I would venture to say that the problem you mention is really a non problem. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
ports/121370
Can you take a look at that patch and commit it. The PR is 3 weeks old. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/121370 Many Thanks -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
Doug Barton píše v čt 20. 03. 2008 v 13:12 -0700: Pav Lucistnik wrote: Doug Barton píše v c(t 20. 03. 2008 v 01:05 -0700: On Thu, 20 Mar 2008, Michel Talon wrote: i would venture to say that such an utility should be able to upgrade things based of *binary* packages, and consequently that portmaster is not a suitable candidate. That ability is not included in the current requirements document, and was not specifically mentioned the last time we had the discussion on the list. If the portmgr folks intend that to be a requirement, the current ideas list entry should be amended. Yes, I think ability to work with packages on a remote FTP site with no local /usr/ports, solely relying on an INDEX file, is a solid must have requirement. I have added that to the entry in the Ideas page. Fair enough, but can we please come quickly to a consensus on what _all_ of the requirements should be? Two things I'd like to avoid. One is the feeling that no matter how many hoops I jump through, there is always going to be one more placed in my path because we really don't want portmaster in the base. I will install portmaster on my machine now and give it a tryout. Tell you what I like and what I dislike about it. I'm afraid the moment I start pushing for making something that is not portupgrade a new de-facto standard, it will turn into a muddy politics really fast. Well I guess I have to bite a bullet. And I don't think anyone started talking to the src guys about including it in base system yet. The other is frustration on the part of any student brave enough to tackle this task. It is not marked as a Summer of Code suggested project. Only the parallelization task is. I think we should be pushing our packages and package-only modes of operation to the mainstream users. Especially now when we can afford to build a complete package set for all existing platforms/architectures on a 48-hour cycle basis. I would be more sympathetic to this idea if we could somehow push security-sensitive package builds up to the top of the list (so they would be available ASAP), but the last time I inquired about this I was told it isn't possible. It's not possible at the moment. There are dreams of having an on-commit action that would trigger a rebuild of the changed port and only the changed port on all platforms. But I feel this would be fairly hard to implement inside the current pointyhat framework. There should also be an overhaul of current ftp mirrors infrastructure, which might not be able to sustain the constant flow of new packages. You also need to look at the other side of that, which is an exponential increase in the number of package downloads, and the incumbent costs in terms of bandwidth, processor time, etc. My impression is that current mirrors are vastly underutilized, and that it's not a big problem to get more mirrors if we ask. But the current cvsup/rsync method of distributing changes from ftp-master onto mirrors is not good enough. It introduces a huge latency, it's unpredictable and inconsistent. We would need to build a CDN for packages, ideally. Also, if we want to get serious about packages, we need to ensure atomic updates of package sets on the ftp master and on the mirrors. We currently don't do that. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Quantum physics was developed in the 1930's, as a result of a bet between Albert Einstein and Niels Bohr, to see who could come up with the most ridiculous theory and still have it published. signature.asc Description: Toto je digitálně podepsaná část zprávy
