Re: ports and PBIs
On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer jul...@elischer.org wrote: sorry for the cross-post.. Last night at the Bay Area FreeBSD Users Group meeting we had a discussion about ports, and what is good about them and what is bad about them. This has been a topic of discussion quite a bit recently and we were looking for a solution that would allow us to keep the good parts of the current ports system but would allow us to give a better user experience for non guru users. The scheme we came up with involves a merging of the ports tree and the PBI system, developed for PC-BSD. Basically, the addition of a makepbi keyword in the .mk files to allow the automatic generation of PBIs for 'simple' ports such as 'cowsay' (the canonical simple app). More complicated apps would need manual work in Makefile or in a separate pbi-recipe file, but once the support was done we could proceed one port at a time. Not all ports make sense in a PBI format. (e.g. libraries etc. may not) I for one support this Idea, and at a BoF FreeBSD Desktop session at BSDCan 2008 one of my suggestions was to have FreeBSD bless PBI's I think this is good For PC-BSD. and in return it is GREAT for FreeBSD, as it will widen the user base and hopefully attract a few more good developers. keep this discussion going, because there isn't mush of a downside so far as I can see. Sam Fourman Jr. One issue that was raised is the increase of storage overhead when using PBI packages as they include a copy of all required libraries and resources, which means that one would very quickly get duplicate copies of things. Our suggestions include the ability of the PBI management software to resolve and (using hard links) eliminate duplicate items. This is not as easy as it sounds but can be achieved using a special variant of 'objcopy' (at least that is our theory). The aim is to make all apps installed on a system much more resilient to dependency problems. In addition there was discussion on how builds need to be doable as non-root uids sometimes, and that users on a system should be able to install packages (PBIs) as thie selves to get local versions of apps for themselves. Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. Julian ___ 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 ___ 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: cvs commit: ports/graphics/ocaml-images Makefile ports/graphics/ocaml-images/files patch-src_gifwrite.c
The Restless Daemon identified a depend_object error while trying to build: ocaml-images-3.0.2_3,2 maintained by po...@freebsd.org Makefile ident: $FreeBSD: ports/graphics/ocaml-images/Makefile,v 1.29 2010/04/09 10:06:43 stas Exp $ Excerpt from http://QAT.TecNik93.com/logs/8-STABLE-NPD/ocaml-images-3.0.2_3,2.log : library (10401): libpng version 1.4.1 - February 25, 2010 pngtest (10401): libpng version 1.4.1 - February 25, 2010 sizeof(png_struct)=1072, sizeof(png_info)=368 Testing pngtest.png: Pass 0: rwrwrwrwrwrwrwrwrw Pass 1: rwrwrwrwrwrwrwrwrw Pass 2: rwrwrwrwrwrwrwrw Pass 3: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw Pass 4: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw Pass 5: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrw Pass 6: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrw PASS (9782 zero samples) Filter 0 was used 21 times Filter 1 was used 15 times Filter 2 was used 52 times Filter 3 was used 10 times Filter 4 was used 33 times tIME = 7 Jun 1996 17:58:08 + libpng passes test === Installing for png-1.4.1_1 === Generating temporary packing list === Checking if graphics/png already installed === png-1.4.1_1 is already installed 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 graphics/png without deleting it first, set the variable FORCE_PKG_REGISTER in your environment or the make install command line. *** Error code 1 Stop in /a/ports/graphics/png. *** Error code 1 Stop in /a/ports/graphics/ocaml-images. build of /usr/ports/graphics/ocaml-images ended at Sat Apr 10 06:15:31 UTC 2010 PortsMon page for the port: http://portsmon.freebsd.org/portoverview.py?category=graphicsportname=ocaml-images The build which triggered this BotMail was done under tinderbox-3.3_3; dsversion: 3.2.1 on RELENG_8 on amd64, kern.smp.cpus: 8 with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/ Thanks for your work on making FreeBSD better, -- QAT - your friendly neighborhood Daemon, preparing a heck of an error trapping system: - HMC and EOI? - Halt, Melt and Catch fire or Execute Operator Immediately. ___ 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: ports and PBIs
On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More amvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer jul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Sam Fourman Jr. Fourman Networks ___ 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
Now OK (Re: cvs commit: ports/graphics/ocaml-images Makefile)
graphics/ocaml-images, which was previously failing is OK after this commit. Thanks for fixing it! A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/ Thanks for your work on making FreeBSD better, -- QAT - your friendly neighborhood Daemon, preparing a heck of an error trapping system: - HMC and EOI? - Halt, Melt and Catch fire or Execute Operator Immediately. ___ 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: [RFC] Remove pkg_add -C (chroot functionality)
On Wed, Apr 7, 2010 at 8:49 PM, Garrett Cooper yanef...@gmail.com wrote: On Wed, Apr 7, 2010 at 7:22 PM, Tim Kientzle kient...@freebsd.org wrote: Garrett Cooper wrote: There's an outstanding bug to fix chroot(2)'ing functionality with pkg_add(1) [1]. Anyone that has tried this functionality knows that it's currently crippled If it's currently broken, it's better to simply remove it. I'm not sure I understand why anyone wants pkg_add to call chroot(2) at the top, though. As you pointed out, chroot pkg_add exists already. The feature we need should: * update $ROOTDIR/var/db/pkg * Add $ROOTDIR as a prefix to all installed file locations This would allow pkg_add when running outside of a chroot to install packages into a chrooted system, which is what you can't easily do with chroot pkg_add. As discussed in #bsdports with flz, it's much more complicated because in the future we'll most likely have mainstream support for cross-building where this isn't possible, i.e. build arm on i386 -- the point is that there are some steps that must be run on the target system or chroot, and this quite frankly isn't possible without being able to install directly on the target. Regardless, cross-building right now requires that one define the proper environment, and again that can't be delivered with pkg_add without introducing unneeded complexity. Point being, if someone wants to chroot, and they understand the complete exercise, or if we have documentation provided which demonstrates how to do so, people will use it, and potentially grow upon it in a positive way. Right now this is just a vestige of brokenness in pkg_install that should go IMO. Of course, this isn't particularly easy to do when forking tar(1), so the libarchive integration might be a necessary prerequisite. (Command-line tar doesn't support re-rooting absolute paths. There is a --chroot option to tar, but it's currently broken in some rather complex ways. As I'm composing this message, I'm starting to wonder if it also should not use chroot(2). Hmmm) The hard part is @exec/@unexec. On the one hand, you don't necessarily want to require the install dependencies of a package to be installed in the chroot, which argues against running those under chroot(2). On the other hand, a lot of the commands used within @exec/@unexec manipulate common system databases (e.g., ldconfig), which argues that those commands should be run under chroot(2). Bingo -- that is the cruxt of the problem with doing chroot(2) with pkg_add. From a support perspective it's a nightmare because when something does go south, you're up a crik without a paddle trying to figure out what the heck is going on... it's better for us that someone is running with a stable, pre-defined system than try and force them to use a home grown / unknown method built around a shaky base. It's been two days without a lot of commentary. Expanding to a larger audience... Thanks, -Garrett ___ 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
Trivial PR, fix package-noinstall
This morning I took a look at my outstanding PRs. There are is a ports PR I consider old and trivial: This one fixes a bug in the package-noinstall target. wxs told me that he prefers my proposed fix over his own: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144164 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: Trivial PR, fix package-noinstall
On Sat, Apr 10, 2010 at 2:29 AM, Dominic Fandrey kamik...@bsdforen.de wrote:
This morning I took a look at my outstanding PRs. There are
is a ports PR I consider old and trivial:
This one fixes a bug in the package-noinstall target. wxs told
me that he prefers my proposed fix over his own:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144164
This suggested fix completely breaks pkg_creates operation because it
does a chdir(2) prior to package creation (from
.../usr.sbin/pkg_install/create/perform.c:555):
if (chdir(log_dir) == FAIL) {
warnx(can't change directory to '%s'!, log_dir);
return FALSE;
}
The goal is to expand use of the install and deinstall scripts, not
break them in ports; this would be counterproductive to what we want
to do.
FWIW, I've thought this over and and user modifiable scripts should
not be in packages; they should instead be example files which don't
conflict with real configuration files. This is already the case for
several ports, but not all ports. If we did this, it would solve the
problem we've had with ports removing or overwriting user config files
simply and easily. I wonder if other folks agree with me or not.
Thanks,
-Garrett
___
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: Trivial PR, fix package-noinstall
On Sat, 10 Apr 2010 03:18:42 -0700 Garrett Cooper yanef...@gmail.com wrote: FWIW, I've thought this over and and user modifiable scripts should not be in packages; they should instead be example files which don't conflict with real configuration files. This is already the case for several ports, but not all ports. If we did this, it would solve the problem we've had with ports removing or overwriting user config files simply and easily. I wonder if other folks agree with me or not. I agree as long as the port emits a message pointing the user at the example configuration files. In some cases more than this may be needed since man pages might refer to configuration files which no longer exist. -- Gary Jennejohn ___ 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: Trivial PR, fix package-noinstall
On 10/04/2010 12:49, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 3:44 AM, Dominic Fandrey kamik...@bsdforen.de wrote:
On 10/04/2010 12:18, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 2:29 AM, Dominic Fandrey kamik...@bsdforen.de
wrote:
This morning I took a look at my outstanding PRs. There are
is a ports PR I consider old and trivial:
This one fixes a bug in the package-noinstall target. wxs told
me that he prefers my proposed fix over his own:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144164
This suggested fix completely breaks pkg_creates operation because it
does a chdir(2) prior to package creation (from
.../usr.sbin/pkg_install/create/perform.c:555):
if (chdir(log_dir) == FAIL) {
warnx(can't change directory to '%s'!, log_dir);
return FALSE;
}
I don't see what appears to be the problem. The fix is tested,
there is no chdiring and pkg_create is not modified in any way.
All it does is change the parameters pkg_create is called with.
Have you tested in the following cases:
1. With the pkg_install scripts.
2. Without the pkg_install scripts.
If not, then you need to do that before asking for someone to
commit your code :).
The do-package code is used by the package and the package-noinstall
targets.
package-noinstall is called by package-recursive on ALL-DEPENDS.
I.e. it is only used on completely installed packages, just what
pkg_create -b was made for.
The regular package target is always run after install (search for
Main logic in bsd.port.mk). So do-package is only called after
install has completed, hence the code can, in every case, rely on
logdir containing all required data.
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: Trivial PR, fix package-noinstall
On 10/04/2010 13:11, Gary Jennejohn wrote: On Sat, 10 Apr 2010 03:18:42 -0700 Garrett Cooper yanef...@gmail.com wrote: FWIW, I've thought this over and and user modifiable scripts should not be in packages; they should instead be example files which don't conflict with real configuration files. This is already the case for several ports, but not all ports. If we did this, it would solve the problem we've had with ports removing or overwriting user config files simply and easily. I wonder if other folks agree with me or not. I agree as long as the port emits a message pointing the user at the example configuration files. I think noone ever agreed that installing user changeable configuration files was a good idea and .sample files or include folders are both prominent and widely accepted solutions. However this only ever entered the discussion because of a misunderstanding. I'd prefer to keep the discussion on topic and avoid the million I agree posts on something no one ever disagreed to. 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: ports and PBIs
On Sat, Apr 10, 2010 at 2:20 AM, Garrett Cooper yanef...@gmail.com wrote: On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. sfour...@gmail.com wrote: On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More amvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer jul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). I wasn't suggesting that the current way Gentoo did Masking was the correct way, in fact you have valid points that I agree with and I used Gentoo last Week :) What I like is that, most of the portage development in done in tree, maybe the real solution is, to just have a development and release ports tree? right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. Again, I agree with you, I just want a easier way to test these large ports. I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. pkg_add does work, I have done it several times, upon learning about PBI's a few years back I wondered to myself, why not just use packages,and make some sort of GUI to add a icon to the whole ordeal. but now I get the Idea of dependencies,it pleges evey Open source OS, even ubuntu breaks every now and again. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at size difference. Here's just one sample: $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of
Re: ports and PBIs
On 4/10/10 12:20 AM, Garrett Cooper wrote: On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.sfour...@gmail.com wrote: On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande Moreamvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischerjul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. yes but there are still dependency problems if you want to install a single package and you installed all the previous ones a year ago. With PBIs each package is self standing, so you can install one and not worry if it requires a different version of some library to what you installed last year. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 . Big difference in size (13.25 fold difference). Yes but that is a worst case thing. We are talking about making a system where the PBIs contain all the libraries needed but that only some of them are installed, when there is not already the same one (i.e. identical) installed by a previous PBI. so if you installed, say, 20 PBI from the same 'set' you woudl only be installing one copy of the libraries that PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a
x11/nvidia-driver: VDPAU headers in /usr/local/include/vdpau now
Hello there,
Over the last several months, I've had received several questions on
maybe we could move VDPAU headers to /usr/local/include/vdpau (nVidia
reference driver and our port normally installed them under ${DOCSDIR}).
After short discussion with nVidia folks and maintainers that are
particularly interested in better location of VDPAU headers, it was
decided that they indeed be better placed under /usr/local/include/vdpau.
The latest update of the port now provides two symlinks for that matter,
which should obsolete other ports' hacks like copying them manually to
local build tree. Even more, those hacks could easily break with next
update of nVidia driver port, as it was decided to move them from docs
completely onto new location. Hence this email. :-)
Thanks.
./danfe
___
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: x11/nvidia-driver: VDPAU headers in /usr/local/include/vdpau now
On Sat, 10 Apr 2010 15:34:45 +
Alexey Dokuchaev da...@freebsd.org wrote:
Hello there,
Over the last several months, I've had received several questions on
maybe we could move VDPAU headers to /usr/local/include/vdpau (nVidia
reference driver and our port normally installed them under
${DOCSDIR}).
After short discussion with nVidia folks and maintainers that are
particularly interested in better location of VDPAU headers, it was
decided that they indeed be better placed
under /usr/local/include/vdpau. The latest update of the port now
provides two symlinks for that matter, which should obsolete other
ports' hacks like copying them manually to local build tree. Even
more, those hacks could easily break with next update of nVidia
driver port, as it was decided to move them from docs completely onto
new location. Hence this email. :-)
Umm, why were headers installed in DOCSDIR in the first place?
--
IOnut - Un^d^dregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B
signature.asc
Description: PGP signature
Re: x11/nvidia-driver: VDPAU headers in /usr/local/include/vdpau now
On Sat, Apr 10, 2010 at 07:06:01PM +0300, Ion-Mihai Tetcu wrote:
On Sat, 10 Apr 2010 15:34:45 +
Alexey Dokuchaev da...@freebsd.org wrote:
Over the last several months, I've had received several questions on
maybe we could move VDPAU headers to /usr/local/include/vdpau (nVidia
reference driver and our port normally installed them under
${DOCSDIR}).
Umm, why were headers installed in DOCSDIR in the first place?
From our discussion with nVidia folks:
The only reason the headers are in the doc directory is because the
OpenGL headers are also in the doc directory. We simply handled the
two sets of headers the same. I don't know why the OpenGL headers
aren't installed in a compiler-accessible location. This issue was
briefly mentioned when creating our FreeBSD VDPAU packaging, but
there was no specific mention of the reasoning behind it.
Anyway, I hope things will straighten out soon enough.
./danfe
___
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: PHP 5.3....
Albert Gabàs | Astabis wrote: Dear Ale, I have some problems with the latest iocube loader for php version 5.3. I'm trying to downgrade the php to the 5.2 version, but I can't complete the downgrade due problems with pcre. How can I downgrade the 5.3 to 5.2 version if the php5-pcre has been removed?? Regards -- Albert Gabàs - Astabis Information Risk Management Movil: +34 687 733 222 | Oficina: +34 932 417 962 Directo: +34 931 145 262 | Fax: +34 932 400 545 Emergencias en servidores: +34 668 887 123 SkypeID: albert.gabas Le informamos que los datos personales que facilite/ha facilitado pasarán a formar parte de un fichero responsabilidad de ASTABIS IRM, S.L. y que tiene por finalidad gestionar las relaciones con usted. Tiene derecho al acceso, rectificación cancelación y oposición en nuestro domicilio social sito en la calle Balmes, 297 1º 2ª de Barcelona o a la dirección de e-mail l...@astabis.com Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. This message is intended exclusively for its addressee and may contain information that is confidential and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. ___ 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 Hi Albert, you can use the porteasy (/usr/ports/ports-mgmt/porteasy): With porteasy you can use one old ports from CVS repository, example: # porteasy -p /tmp/ports -D '6 months ago' -v -u lang/php5 I create one post for this (sorry, only in portuguese): http://www.luizgustavo.pro.br/blog/2010/02/22/porteasy-gerencia-de-ports-no-freebsd/ Regards -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 2642-3799 / 75820594 Blog: http://www.luizgustavo.pro.br ___ 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: ports and PBIs
On 4/10/10 3:35 AM, Garrett Cooper wrote: On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischerjul...@elischer.org wrote: On 4/10/10 12:20 AM, Garrett Cooper wrote: On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.sfour...@gmail.com wrote: On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande Moreamvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischerjul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. yes but there are still dependency problems if you want to install a single package and you installed all the previous ones a year ago. With PBIs each package is self standing, so you can install one and not worry if it requires a different version of some library to what you installed last year. If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. ok that's your opinion n the matter. I for one think htat hte default ettin for PBIs to install all the dependencies, in this day of 1TB drives, makes sense and is a good capability for us to have, even if not everyone needs to use it. If you can do this
Re: ports and PBIs
On Sat, Apr 10, 2010 at 8:18 AM, k...@pcbsd.org wrote: On Sat 10/04/10 3:35 AM , Garrett Cooper yanef...@gmail.com wrote: [...] yes but there are still dependency problems if you want to install a single package and you installed all the previous ones a year ago. With PBIs each package is self standing, so you can install one and not worry if it requires a different version of some library to what you installed last year. If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. Incorrect. The difference is in complexity at install-time. Even if you improve the package manager to better resolve and upgrade all related dependencies as a result of doing a firefox upgrade, the fact still remains that just to update one package, you may have to also update a TON of various packages / libraries, any of which may be critical to other applications on your system. If just a single one of those things fails, you can end up breaking a lot of applications on your system or even your entire desktop. PBI system simplifies this process. Updating firefox, since its self-contained, does NOT run the risk of borking anything else on the system. You don't need to work about libpng, libjpeg, or some other seemingly trivial library (to the end user) causing a huge breakage for xorg, or KDE/Gnome, etc. This in my opinion is the fatal flaw of pretty much every open-source system out there right now. Something both windows mac have recognized and dealt with. We instead try to write more and more complex package resolvers, while failing to address the main issue, that with such a complex chain of dependencies for something as simple as upgrading firefox, it increases the chances exponentially that something will break and ruin your day / weekend. PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a mirror referenced in pbidir.com, the number is currently under 500~750 PBIs -- this is drastically smaller than the number of binary packages produced by ports on a regular basis for FreeBSD. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Packages are more of the answer IMO, not PBIs. PBIs are merely a different set of contents and different means of delivering those contents, and while I like the idea of point - click - install, I'm not ready to create unnecessary complexity by having libraries rev'ed according to what the maintainer A believes are correct, even though maintainer B set it differently, and I'm not interested in sacrificing disk space for this reason. If I wanted to use a packaging scheme like this, I should be using Mac OSX as my primary operating system. well no-one is going to make you use PBIs Yes, but if I now have to waste more bandwidth and disk space installing packages, why shouldn't I go to another operating system? Switching over to PBIs will reel in more desktop and entry-level sysadmins, etc, but I fear that it will isolate folks in the embedded market as well as several more seasoned users because of the implications involved with the extra bandwidth requirement and footprint. This gave me a bit of a chuckle. PBI would not be intended as a replacement for ports, rather a utilizing of ports in such a way that we can start building self-contained, stand-alone binaries for end-users and those of us who value their time more than a few MB of disk space. Considering at every BSD conference it seems that the majority of developers are running Mac laptops, it would seem that even some developers agree with the principle, they just aren't doing it on FreeBSD. :) I also, noticed this, and a
Re: ports and PBIs
Garrett Cooper wrote: If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. I'm not convinced that the simple update command you mention is actually feasible, much less desirable. (If I want to try out the new Firefox, why does that imply that my year-old Gimp has to be upgraded?) As for feasibility, here's the easy problem: A2.7 requires B3.6 ... one year passes ... A4.8 now requires B7.2 But A4.8 is incompatible with B3.6 and A2.7 is incompatible with B7.2. So neither A nor B can be updated separately without breaking the system. Here's the hard problem: A2.7 requires B3.6 ... one year passes ... I want to install C1.0 which requires B7.2 but there hasn't been a new release of A that works with B7.2. So I now simply cannot have both C1.0 and A2.7 installed at the same time because they require different versions of B. PBI avoids both of these problems. It may be unsuitable for embedded systems[1], but I see no reason we should not extend the existing ports/packages system with additional tools that target certain use cases, and PBI seems a good fit for the desktop case. Tim [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. It's even easy to handle at install time: * Installer writes libfoo-2.8.7.so to /Package/Shared/libfoo-2.8.7.so-temp-PID of installer * Installer computes hash of file as it's written * Installer renames file (delete if rename fails with EEXIST) * Installer writes symlink or hardlink into /Package/Bar ___ 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: ports and PBIs
On 4/10/10 12:07 PM, Tim Kientzle wrote: Garrett Cooper wrote: If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. I'm not convinced that the simple update command you mention is actually feasible, much less desirable. (If I want to try out the new Firefox, why does that imply that my year-old Gimp has to be upgraded?) As for feasibility, here's the easy problem: A2.7 requires B3.6 ... one year passes ... A4.8 now requires B7.2 But A4.8 is incompatible with B3.6 and A2.7 is incompatible with B7.2. So neither A nor B can be updated separately without breaking the system. Here's the hard problem: A2.7 requires B3.6 ... one year passes ... I want to install C1.0 which requires B7.2 but there hasn't been a new release of A that works with B7.2. So I now simply cannot have both C1.0 and A2.7 installed at the same time because they require different versions of B. PBI avoids both of these problems. It may be unsuitable for embedded systems[1], but I see no reason we should not extend the existing ports/packages system with additional tools that target certain use cases, and PBI seems a good fit for the desktop case. Tim [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. It's even easy to handle at install time: * Installer writes libfoo-2.8.7.so to /Package/Shared/libfoo-2.8.7.so-temp-PID of installer * Installer computes hash of file as it's written * Installer renames file (delete if rename fails with EEXIST) * Installer writes symlink or hardlink into /Package/Bar yeah that's more or less what we were thinking.. hardlinks allow you to garbage collect when the last pbi that needs something is replaced/removed. It's also to handle the cases where library A wants library B. you don't want library A in the shared place looking for B back in the original PBI directory so there may need to be some patching up. ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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
openssl port versioning
Hi, There is a bunch of ports related to PKI (security/p5-openxpki*) which requires exactly openssl-0.9.8x, because: - openssl-0.9.8x version (unlike openssl-0.9.7x) has full support for utf-8, which is essential for complex PKI software. - this bunch of ports is huge and complex, heavily uses low-level functions of openssl-0.9.8x, and it will take quite some time to adapt for openssl-1.0.0+ But today we have openssl from port with version 1.0.0 only. Freebsd-6 or less has base openssl-0.9.7 which is bad for security/p5-openxpki*. Seems like we have to stop compiling this port on freebsd-6 or less altogether. Do you think if it is possible to return openssl-0.9.8x to the ports, just to make people with FreeBSD-6 happy. Regards, Sergei ___ 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: PHP 5.3....
Great tool, thank you very much Luiz. Regards -- Albert Gabàs - Astabis Information Risk Management Movil: +34 687 733 222 | Oficina: +34 932 417 962 Directo: +34 931 145 262 | Fax: +34 932 400 545 Emergencias en servidores: +34 668 887 123 SkypeID: albert.gabas Le informamos que los datos personales que facilite/ha facilitado pasarán a formar parte de un fichero responsabilidad de ASTABIS IRM, S.L. y que tiene por finalidad gestionar las relaciones con usted. Tiene derecho al acceso, rectificación cancelación y oposición en nuestro domicilio social sito en la calle Balmes, 297 1º 2ª de Barcelona o a la dirección de e-mail l...@astabis.com Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. This message is intended exclusively for its addressee and may contain information that is confidential and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. -Mensaje original- De: Luiz Gustavo Costa [mailto:luizgust...@luizgustavo.pro.br] Enviado el: sábado, 10 de abril de 2010 19:33 Para: Albert Gabàs | Astabis CC: a...@freebsd.org; po...@freebsd.org Asunto: Re: PHP 5.3 Albert Gabàs | Astabis wrote: Dear Ale, I have some problems with the latest iocube loader for php version 5.3. I'm trying to downgrade the php to the 5.2 version, but I can't complete the downgrade due problems with pcre. How can I downgrade the 5.3 to 5.2 version if the php5-pcre has been removed?? Regards -- Albert Gabàs - Astabis Information Risk Management Movil: +34 687 733 222 | Oficina: +34 932 417 962 Directo: +34 931 145 262 | Fax: +34 932 400 545 Emergencias en servidores: +34 668 887 123 SkypeID: albert.gabas Le informamos que los datos personales que facilite/ha facilitado pasarán a formar parte de un fichero responsabilidad de ASTABIS IRM, S.L. y que tiene por finalidad gestionar las relaciones con usted. Tiene derecho al acceso, rectificación cancelación y oposición en nuestro domicilio social sito en la calle Balmes, 297 1º 2ª de Barcelona o a la dirección de e-mail l...@astabis.com Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. This message is intended exclusively for its addressee and may contain information that is confidential and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. ___ 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 Hi Albert, you can use the porteasy (/usr/ports/ports-mgmt/porteasy): With porteasy you can use one old ports from CVS repository, example: # porteasy -p /tmp/ports -D '6 months ago' -v -u lang/php5 I create one post for this (sorry, only in portuguese): http://www.luizgustavo.pro.br/blog/2010/02/22/porteasy-gerencia-de-ports-no- freebsd/ Regards -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 2642-3799 / 75820594 Blog: http://www.luizgustavo.pro.br ___ 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: Trivial PR, fix package-noinstall
On Sat, Apr 10, 2010 at 4:26 AM, Dominic Fandrey kamik...@bsdforen.de wrote:
On 10/04/2010 12:49, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 3:44 AM, Dominic Fandrey kamik...@bsdforen.de
wrote:
On 10/04/2010 12:18, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 2:29 AM, Dominic Fandrey kamik...@bsdforen.de
wrote:
This morning I took a look at my outstanding PRs. There are
is a ports PR I consider old and trivial:
This one fixes a bug in the package-noinstall target. wxs told
me that he prefers my proposed fix over his own:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144164
This suggested fix completely breaks pkg_creates operation because it
does a chdir(2) prior to package creation (from
.../usr.sbin/pkg_install/create/perform.c:555):
if (chdir(log_dir) == FAIL) {
warnx(can't change directory to '%s'!, log_dir);
return FALSE;
}
I don't see what appears to be the problem. The fix is tested,
there is no chdiring and pkg_create is not modified in any way.
All it does is change the parameters pkg_create is called with.
Have you tested in the following cases:
1. With the pkg_install scripts.
2. Without the pkg_install scripts.
If not, then you need to do that before asking for someone to
commit your code :).
The do-package code is used by the package and the package-noinstall
targets.
package-noinstall is called by package-recursive on ALL-DEPENDS.
I.e. it is only used on completely installed packages, just what
pkg_create -b was made for.
The regular package target is always run after install (search for
Main logic in bsd.port.mk). So do-package is only called after
install has completed, hence the code can, in every case, rely on
logdir containing all required data.
Ok, interesting. If you look at another spot in bsd.port.mk, there's
another area where +INSTALL and friends are installed:
fake-pkg:
# ...
if [ -f ${PKGINSTALL} ]; then \
${CP} ${PKGINSTALL} ${PKG_DBDIR}/${PKGNAME}/+INSTALL; \
fi; \
if [ -f ${PKGDEINSTALL} ]; then \
${CP} ${PKGDEINSTALL} ${PKG_DBDIR}/${PKGNAME}/+DEINSTALL; \
fi; \
if [ -f ${PKGREQ} ]; then \
${CP} ${PKGREQ} ${PKG_DBDIR}/${PKGNAME}/+REQUIRE; \
if [ -f ${PKGMESSAGE} ]; then \
${CP} ${PKGMESSAGE} ${PKG_DBDIR}/${PKGNAME}/+DISPLAY; \
fi; \
# ...
So if I don't define NO_PKG_REGISTER and I define FORCE_PKG_REGISTER,
then this logic will be executed.
This change does need to be tested for the make package-noinstall case
with pkg-install, pkg-deinstall, etc being present and not being
present [in their .in files form and non-.in files form]. Otherwise
this is going to potentially introduce a regression into bsd.port.mk.
Thanks,
-Garrett
___
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: openssl port versioning
On Sun, Apr 11, 2010 at 01:07:42AM +0400, Sergei Vyshenski wrote: Do you think if it is possible to return openssl-0.9.8x to the ports, just to make people with FreeBSD-6 happy. fwiw, 6.4 EOL is on 11/30/2010, so you're going to be looking at upgrading some time this year anyways. This business of supporting 4 branches of FreeBSD is becoming a bit burdensome in the meantime ... mcl ___ 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: ports and PBIs
Julian Elischer wrote: On 4/10/10 12:07 PM, Tim Kientzle wrote: [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. yeah that's more or less what we were thinking.. hardlinks allow you to garbage collect when the last pbi that needs something is replaced/removed. The point of /Package/Shared in this design is basically that it provides a list of all of the files that can be shared, so you avoid doing a full disk search to identify other places that might have this file. You could accomplish the same goal by building and storing a database of sharable files somewhere, of course. (Curiously, no one has mentioned filesystem-level deduping yet as the big hammer solution... ;-) The LD_LIBRARY_PATH issue is the most interesting problem here. I don't immediately see a solution that doesn't include teaching ld-elf.so.1 about some form of per-application library path. Tim ___ 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
CFT: games/nwndata and games/linux-nwnclient ports
I have found a bit of time to update the games/nwndata and
games/linux-nwnclient ports to more recent versions along with Diamond
support. The list of changes--I think I listed them all--for each port
is as follows:
games/nwndata (versions are original 1.29_3 and Diamond 1.61):
- Install from the data files directly from the Diamond DVD, if
provided. A Diamond install includes the Shadows of Undrentide,
Hordes of the Underdark and Kingmaker expansions. The port version is
1.61 when using the Diamond DVD.
games/linux-nwnclient:
- Update client to v1.69 which is the final release from BioWare.
- Remove ARCH requirement for i386; let the install of the Linux base
determine if the port is allowed or not.
- Detect if the original or Diamond game files were installed in
games/nwndata to install the appropriate client.
- Add an option to install the NWMovies/BinkPlayer patch to play in-game
movies for the Diamond client. This includes a rewritten script (from
Perl to shell) to remove the need for Linux Perl to run it. The
script includes a method to skip movies, especially the intro movies,
as noted in pkg-message. Default to off.
- In the nwn script, remove dead links in and rebuild ${HOME}/.nwn.
This allows moving between the original and Diamond editions without
confusing (resulting in segmentation faults) the client.
- Set SDL_AUDIODRIVER to dsp by default to remove warnings from SDL
concerning audio setup.
- Disallow core files as these are commonly seen when the game exits.
Fortunately, the segmentation fault does not affect play nor the
configuration files.
I do realize there are other editions of the game, but I lack copies of
them as well as time to test them even if I did. I am sorry about that.
It is fortunate that archivers/p7zip exists else an install of wine
would be required to extract the Kingmaker expansion pack. If something
in base can also do it, please let me know.
Sean
--
s...@freebsd.org
___
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: CFT: games/nwndata and games/linux-nwnclient ports
On Sat, 10 Apr 2010, Sean C. Farley wrote:
I have found a bit of time to update the games/nwndata and
games/linux-nwnclient ports to more recent versions along with Diamond
support. The list of changes--I think I listed them all--for each
port is as follows:
games/nwndata (versions are original 1.29_3 and Diamond 1.61):
- Install from the data files directly from the Diamond DVD, if
provided. A Diamond install includes the Shadows of Undrentide,
Hordes of the Underdark and Kingmaker expansions. The port version is
1.61 when using the Diamond DVD.
games/linux-nwnclient:
- Update client to v1.69 which is the final release from BioWare.
- Remove ARCH requirement for i386; let the install of the Linux base
determine if the port is allowed or not.
- Detect if the original or Diamond game files were installed in
games/nwndata to install the appropriate client.
- Add an option to install the NWMovies/BinkPlayer patch to play in-game
movies for the Diamond client. This includes a rewritten script (from
Perl to shell) to remove the need for Linux Perl to run it. The
script includes a method to skip movies, especially the intro movies,
as noted in pkg-message. Default to off.
- In the nwn script, remove dead links in and rebuild ${HOME}/.nwn.
This allows moving between the original and Diamond editions without
confusing (resulting in segmentation faults) the client.
- Set SDL_AUDIODRIVER to dsp by default to remove warnings from SDL
concerning audio setup.
- Disallow core files as these are commonly seen when the game exits.
Fortunately, the segmentation fault does not affect play nor the
configuration files.
I do realize there are other editions of the game, but I lack copies
of them as well as time to test them even if I did. I am sorry about
that.
It is fortunate that archivers/p7zip exists else an install of wine
would be required to extract the Kingmaker expansion pack. If
something in base can also do it, please let me know.
*sigh*
In case anyone would actually like to test these ports, here are the
ports themselves:
http://people.freebsd.org/~scf/linux-nwnclient-port.tar.bz2
http://people.freebsd.org/~scf/nwndata-port.tar.bz2
Sean
--
s...@freebsd.org
___
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: ports and PBIs
Sam Fourman Jr. wrote: I do have a question, assuming PBI's were merged officially into the FreeBSD ports tree, say I had PostgreSQL Server installed, via PBI. then I wanted to tweak a setting so I: cd /usr/ports/databases/postgresql84-server/ make deinstall clean would the PBI at this point be removed? or no because it is self contained? Basically, I believe the proposal here is to add: * make pbi to the ports build system to create a PBI from a port and possibly add * make installpbi * make deinstallpbi to install/deinstall just the resulting PBI. In particular, I don't think anyone is suggesting removing or changing any existing ports/package capability. People who are happy with the existing ports/package system could continue using it exactly as-is. This would imply that you might build Postgres and install it both as a port/package and simultaneously as a PBI. I'm not sure what that would mean, though. The big question, of course: what impact would the addition of make pbi have on existing port/package support efforts? Is this creating extra work for existing maintainers? Should it be optional (enabled per-port) or somehow default? I suspect the next step is for someone to put forward a proposed implementation of make pbi so those interested can start trying it out and see what the impacts are. (If only the GSoC proposal deadline hadn't already passed. ;-) Tim ___ 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: [BROKEN] ports/misc/rfc with -i flag
On Wed, 31 Mar 2010, jhell wrote: Whenever I use rfc -i to update the index I am getting this: Modem users one moment, it's about 400k (doesn't need to be updated often) original lines = 22143 /usr/local/etc/rfc-index new lines = 7 /usr/local/etc/rfc-index With the contents of: Forbidden You don't have permission to access /in-notes/rfc-index.txt on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. *snip* Does this patch work for you? I changed the location from which the script fetches the rfc-index.txt file. Sean -- s...@freebsd.org ___ 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: [BROKEN] ports/misc/rfc with -i flag
On Sat, 10 Apr 2010, Sean C. Farley wrote:
On Wed, 31 Mar 2010, jhell wrote:
Whenever I use rfc -i to update the index I am getting this:
Modem users one moment, it's about 400k (doesn't need to be updated often)
original lines = 22143 /usr/local/etc/rfc-index
new lines = 7 /usr/local/etc/rfc-index
With the contents of:
Forbidden
You don't have permission to access /in-notes/rfc-index.txt on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an
ErrorDocument to handle the request.
*snip*
Does this patch work for you? I changed the location from which the script
fetches the rfc-index.txt file.
Argh! I just cannot remember to attach patches or URL's today.
Sean
--
s...@freebsd.orgdiff -ruN rfc.orig/Makefile rfc/Makefile
--- rfc.orig/Makefile 2006-04-13 09:06:44.0 -0500
+++ rfc/Makefile2010-04-10 18:31:36.0 -0500
@@ -7,10 +7,11 @@
PORTNAME= rfc
PORTVERSION= 3.2.3
+PORTREVISION= 1
CATEGORIES=misc
MASTER_SITES= http://www.dewn.com/rfc/
-MAINTAINER=sean-free...@farley.org
+MAINTAINER=s...@freebsd.org
COMMENT= Perl script to search for RFC's
RUN_DEPENDS= w3m:${PORTSDIR}/www/w3m
@@ -24,6 +25,8 @@
do-configure:
@${REINPLACE_CMD} -e 's|/usr/local/etc/rfc|${PREFIX}/etc/rfc| ; \
s|/usr/local/etc/nmap|${PREFIX}/share/misc/nmap| ; \
+ s|400k|1024k| ; \
+ s|http://ftp.isi.edu/in-notes|http://www.ietf.org/rfc| ; \
s|/usr/bin/perl|${PERL}|' ${WRKSRC}/${PORTNAME}-${PORTVERSION}
do-install:
___
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: ports and PBIs
not to be a troll but ... ... for those that want the ease-of-use of PBIs, why not just use PC-BSD in the first place? They seem to have their own QA process in place in terms of keeping the various large applications at a sane level. Kernel development could (just like it is on the Macs) be done in some kind of virtualization context. My own experience with helping people who try to run FreeBSD-CURRENT with an up-to-date ports tree is that there are far too many moving parts for it to be dependable. (For more on how often ports get broken by changes in -CURRENT, see http://wiki.freebsd.org/PortsBrokenOnCurrent. Note that that list is not complete.) mcl ___ 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: Trivial PR, fix package-noinstall
On 10/04/2010 23:30, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 4:26 AM, Dominic Fandrey kamik...@bsdforen.de wrote:
On 10/04/2010 12:49, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 3:44 AM, Dominic Fandrey kamik...@bsdforen.de
wrote:
On 10/04/2010 12:18, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 2:29 AM, Dominic Fandrey kamik...@bsdforen.de
wrote:
This morning I took a look at my outstanding PRs. There are
is a ports PR I consider old and trivial:
This one fixes a bug in the package-noinstall target. wxs told
me that he prefers my proposed fix over his own:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144164
This suggested fix completely breaks pkg_creates operation because it
does a chdir(2) prior to package creation (from
.../usr.sbin/pkg_install/create/perform.c:555):
if (chdir(log_dir) == FAIL) {
warnx(can't change directory to '%s'!, log_dir);
return FALSE;
}
I don't see what appears to be the problem. The fix is tested,
there is no chdiring and pkg_create is not modified in any way.
All it does is change the parameters pkg_create is called with.
Have you tested in the following cases:
1. With the pkg_install scripts.
2. Without the pkg_install scripts.
If not, then you need to do that before asking for someone to
commit your code :).
The do-package code is used by the package and the package-noinstall
targets.
package-noinstall is called by package-recursive on ALL-DEPENDS.
I.e. it is only used on completely installed packages, just what
pkg_create -b was made for.
The regular package target is always run after install (search for
Main logic in bsd.port.mk). So do-package is only called after
install has completed, hence the code can, in every case, rely on
logdir containing all required data.
Ok, interesting. If you look at another spot in bsd.port.mk, there's
another area where +INSTALL and friends are installed:
fake-pkg:
# ...
if [ -f ${PKGINSTALL} ]; then \
${CP} ${PKGINSTALL} ${PKG_DBDIR}/${PKGNAME}/+INSTALL; \
fi; \
if [ -f ${PKGDEINSTALL} ]; then \
${CP} ${PKGDEINSTALL} ${PKG_DBDIR}/${PKGNAME}/+DEINSTALL; \
fi; \
if [ -f ${PKGREQ} ]; then \
${CP} ${PKGREQ} ${PKG_DBDIR}/${PKGNAME}/+REQUIRE; \
if [ -f ${PKGMESSAGE} ]; then \
${CP} ${PKGMESSAGE} ${PKG_DBDIR}/${PKGNAME}/+DISPLAY; \
fi; \
# ...
So if I don't define NO_PKG_REGISTER and I define FORCE_PKG_REGISTER,
then this logic will be executed.
Maybe it's because it's 2 AM, but once again I fail to see the
connection to my patch.
This change does need to be tested for the make package-noinstall case
with pkg-install, pkg-deinstall, etc being present and not being
present [in their .in files form and non-.in files form]. Otherwise
this is going to potentially introduce a regression into bsd.port.mk.
If you have a case you suspect might go wrong, please go ahead.
I find myself unable to follow your logic, so I wouldn't even know
the symptoms of something going wrong.
As far as I can see you are talking about install, something my patch
does in no way interfere with. The only connection between install and
package I see is, that the order in which they can be executed is
carved in stone.
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: ports and PBIs
[dropped current@ since it doesn't take non-member posts] Tim Kientzle kient...@freebsd.org wrote: The LD_LIBRARY_PATH issue is the most interesting problem here. I don't immediately see a solution that doesn't include teaching ld-elf.so.1 about some form of per-application library path. Maybe install PBI executables with a wrapper of some sort which would set LD_LIBRARY_PATH and exec the real executable, or build similar functionality into a specialized variant of /usr/lib/crt1.o (which BTW seems not to have a manpage)? Nah, that would be too easy. There must be some lethal flaw in it. ___ 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: ports and PBIs
On 4/10/10 5:43 PM, per...@pluto.rain.com wrote: [dropped current@ since it doesn't take non-member posts] Tim Kientzlekient...@freebsd.org wrote: The LD_LIBRARY_PATH issue is the most interesting problem here. I don't immediately see a solution that doesn't include teaching ld-elf.so.1 about some form of per-application library path. Maybe install PBI executables with a wrapper of some sort which would set LD_LIBRARY_PATH and exec the real executable, or build similar functionality into a specialized variant of /usr/lib/crt1.o (which BTW seems not to have a manpage)? Nah, that would be too easy. There must be some lethal flaw in it. PBIs already do something like this I believe. ___ 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: ports and PBIs
per...@pluto.rain.com wrote: [dropped current@ since it doesn't take non-member posts] Tim Kientzle kient...@freebsd.org wrote: The LD_LIBRARY_PATH issue is the most interesting problem here. I don't immediately see a solution that doesn't include teaching ld-elf.so.1 about some form of per-application library path. Maybe install PBI executables with a wrapper of some sort which would set LD_LIBRARY_PATH and exec the real executable... PBIs already do something like this, but this doesn't work for setuid/setgid executables. Tim ___ 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: ports and PBIs
On Sat, Apr 10, 2010 at 7:47 PM, Mark Linimon lini...@lonesome.com wrote: not to be a troll but ... ... for those that want the ease-of-use of PBIs, why not just use PC-BSD in the first place? They seem to have their own QA process in place in terms of keeping the various large applications at a sane level. Kernel development could (just like it is on the Macs) be done in some kind of virtualization context. My own experience with helping people who try to run FreeBSD-CURRENT with an up-to-date ports tree is that there are far too many moving parts for it to be dependable. (For more on how often ports get broken by changes in -CURRENT, see http://wiki.freebsd.org/PortsBrokenOnCurrent. Note that that list is not complete.) mcl I have tried PC-BSD . I think it has an important draw back : Its theme is changing its colour cyclically . Any person having chronic illness Vertigo can not endure such continuous colour change . I could not find any place to stop that colour cycling other than to remove PC-BSD and install another operating systems onto its hard disk . In FreeBSD ports system , for me , problem is not the current port system . My idea is to have additional information about ports . For example , when a package is desired to be added by pkg_add , it is downloading the requested package , decompressing it , and saying that it is already installed , and it is not necessary to install it . Instead of this , the following structure ( a more proper one may be suggested , this is only an idea ) may be useful : In the ports , instead of using short names , use after a certain character a signature name of the port : As an example : kde4.version.signature.tbz . In installed systems , always install in directories having that name with signature . When an install is attempted , again use pkg_add kde4 for easiness , not its long name , or kde4.version to select a specified version . pkg_add should compute the signature of the installed port kde4, and check its value to installed signature name . If they are different , the port is destroyed ( install it unconditionally ) , otherwise proper . pkg_add should check port kde4... in ports . If their signatures are the same , it is not necessary to download and install it . For the dependencies , with a port kde4.tbz , maintain a kde4.xml listing all the dependencies , in which they may be inspected recursively ( Such lists are displayed in ports related web pages in www.freebsd.org ) . By checking all the related xml files and installed ports in a system , it will be possible to decide installation possibility of a port attempted to be installed without downloading actual port files . In a directory in the system , maintain a subdirectory of ports : Failed_Builds . Into this directory , store names of the packages which failed during building . When a package is attempted to be build , for itself and its dependencies , check that Failed_Builds directory for matching names . If there exists any one of them , do not start to build , because it will not be successfully completed . ( Entries from that directory may be deleted manually to allow build tries , and successful build may check this directory to remove matching entries if it is present . ) This Failed_Builds list is important , because when that information is not used , the same failed build is attempted many times for an install of some packages . Personally , I am not against an additionally available PBI directory in ports tree . Some users may prefer to use them although some packages will be repeatedly stored in different PBI packages and will be downloaded for each of them . Thank you very much . Mehmet Erol Sanliturk ___ 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: openssl port versioning
On Sat, 2010-04-10 at 17:44 -0500, Mark Linimon wrote: On Sun, Apr 11, 2010 at 01:07:42AM +0400, Sergei Vyshenski wrote: Do you think if it is possible to return openssl-0.9.8x to the ports, just to make people with FreeBSD-6 happy. fwiw, 6.4 EOL is on 11/30/2010, so you're going to be looking at upgrading some time this year anyways. This business of supporting 4 branches of FreeBSD is becoming a bit burdensome in the meantime ... +1... I've mostly abandoned 6 and 7 is rapidly falling off of my radar... robert. mcl ___ 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 -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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: ports and PBIs
On Sat, Apr 10, 2010 at 10:03 AM, Julian Elischer jul...@elischer.org wrote: On 4/10/10 3:35 AM, Garrett Cooper wrote: [...] If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. ok that's your opinion n the matter. I for one think htat hte default ettin for PBIs to install all the dependencies, in this day of 1TB drives, makes sense and is a good capability for us to have, even if not everyone needs to use it. It's more than just diskspace though. Consider the fact that now you're going to lose a lot of the memory sharing between shared libs and what-not, and now you'd have to be running N number of daemons . Take PCBSD for instance -- do they really revision packages with unshared dependencies, or are all of the dependencies updated at once? This becomes a big issue as you can't have dissimilar applications like dbus, gamin, openssh, etc running on the same system at one time. How does the PBI layout plan to deal with this kind of conflict -- apart from jails, which would greatly increase the required footprint...? If you can do this with package code, Maybe you will supply the packages.. Not quite sure what you meant here. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 . Big difference in size (13.25 fold difference). Yes but that is a worst case thing. We are talking about making a system where the PBIs contain all the libraries needed but that only some of them are installed, when there is not already the same one (i.e. identical) installed by a previous PBI. so if you installed, say, 20 PBI from the same 'set' you woudl only be installing one copy of the libraries that See above comment. PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a mirror referenced in pbidir.com, the number is currently under 500~750 PBIs -- this is drastically smaller than the number of binary packages produced by ports on a regular basis for FreeBSD. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Packages are more of the answer IMO, not PBIs. PBIs are merely a different set of contents and different means of delivering those contents, and while I like the idea of point - click - install, I'm not ready to create unnecessary complexity by having libraries rev'ed according to what the maintainer A believes are correct, even though maintainer B set it differently, and I'm not interested in sacrificing disk space for this reason. If I wanted to use a packaging scheme like this, I should be using Mac OSX as my primary operating system. well no-one is going to make you use PBIs Yes, but if I now have to waste more bandwidth and disk space installing
