Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Michel Talon wrote: So how to interact with local.sqlite? Thanks Michel, Noted. Would you please consider running send-pr to submit that for man 5 ? Prepending EXAMPLES Appending SEE ALSO pkg(8) There is no src/share/man/man5/local.sqlite.5 in both 10.0-RELEASE branches/-current/ Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 06/02/14 13:58, Rick Miller wrote: On Thu, Feb 6, 2014 at 7:23 AM, Daniel Nebdal dneb...@gmail.com wrote: On Thu, Feb 6, 2014 at 12:41 PM, Rick Miller vmil...@hostileadmin.com wrote: On Thu, Feb 6, 2014 at 2:59 AM, Big Lebowski spankthes...@gmail.com wrote: The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) I echo this sentiment, but I would like to take it a step further and say a certain version or greater. I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. Correct. My wish is the functionality be extended further to mean a certain version *or* newer, encompassing both features. Thus, allowing him to say port-1.1, while I say port-1.4 or newer or even port-1.0 or newer. Python's pip has a nice syntax for this, for example: somepackage=1.6,=1.8 Something like this could be adopted. (Disregarding the discussion if this is technically feasible ATM, I'm sure it will be eventually). -- I guess the Little League is even littler than we thought. -- D. Cavett signature.asc Description: OpenPGP digital signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 08/02/14 14:04, Julian H. Stacey wrote: Michel Talon wrote: So how to interact with local.sqlite? Thanks Michel, Noted. Further, if you really want to debug and inspect with text tools you can simply do $ sqlite3 local.sqlite .dump dump.sql or $ sqlite3 -csv local.sqlite .dump dump.csv From there, I'm sure an impressive pipeline to do just about anything you want can be constructed, if that's what you need. You can also do any kind of additional SQL in that last parameter (.dump is just an sqlite specific SQL meta command) with semicolon separated statements. -- Contestants have been briefed on some questions before the show. signature.asc Description: OpenPGP digital signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 7:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/02/2014 23:57, Kevin Oberman wrote: 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. When I first encountered the ports, way back in 1998 or so, I was completely mind-blown that something so fantastic could exist. Yes, it was revolutionary at the time and right where FreeBSD should be -- leading the rest of the world with great innovations. However, things have changed in the last 16 years. Development of the ports as a global concept has been resting on its laurels a bit, and the rest of the world has caught up, and indeed overtaken. Partly that was due to the mindset of seeing binary packages as a second-class thing; partly due to the old pkg_tools not providing the scope to implement innovative features; partly due to pkg_tools being part of the FreeBSD base, so impossible to update over reasonable timescales due to the requirement to support older RELEASE branches. pkg(8) addresses those problems, and I hope will do so for at least the next decade. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. I don't think it's possible to make a change of this magnitude without upsetting anyone. We have been getting a lot of feedack on the lines of 'Wow! This is great. When can we have feature XYZ?' to which we frequently have to reply that XYZ can't be implemented without breaking compatibility with pkg_tools. Like sub-packages. I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) B. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 2:59 AM, Big Lebowski spankthes...@gmail.com wrote: On Thu, Feb 6, 2014 at 7:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) I echo this sentiment, but I would like to take it a step further and say a certain version or greater. -- Take care Rick Miller ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 12:41 PM, Rick Miller vmil...@hostileadmin.com wrote: On Thu, Feb 6, 2014 at 2:59 AM, Big Lebowski spankthes...@gmail.com wrote: On Thu, Feb 6, 2014 at 7:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) I echo this sentiment, but I would like to take it a step further and say a certain version or greater. I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. -- Daniel Nebdal ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Michel Talon wrote: --Apple-Mail=_102D913B-49CA-4129-972A-758AABCAA293 Content-Type: multipart/alternative; boundary=Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A --Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Junk mail format, not impressed. Use Ascii ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports = builds. As someone who has advocated the use of sqlite to replace the old = database in the filesystem several years before it has been implemented by the new package system, = i can only conclude, like Matthew that you are being absurd. Personal inuendo does not impress. The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. incredibly slow and using system resources in absurd ways. Sqlite obstructs nothing, False. local.sqlite obstructs inspection by find grep text search tools. you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). Moreover i have hard time believing one needs to dissect the package = system (beyond reading the=20 output of pkg info) to debug a port build. One surely needs some = ports/ is not just a plaything for package script addicts. Some use ports/ to make debug exclusively from sources. --Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii htmlhead/headbody style=3Dword-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; pre = Send no junk ! class=3DApple-interchange-newline /div br/body/html= --Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A-- --Apple-Mail=_102D913B-49CA-4129-972A-758AABCAA293 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIbzCCA7Yw 50 lines un-necessary. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
El día Thursday, February 06, 2014 a las 01:27:50PM +0100, Julian H. Stacey escribió: Michel Talon wrote: The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. Since many years I have always compiled my (i.e. the ports I need) from CVS or now SVN ports tree on some fast baquery maschine. After compiling I just did something like: # mkdir PKG # cd PKG # pkg_create -Rnb `cd /var/db/pkg ; ls -C1` and moved the resulting ~1500 packages to my laptops or smaller netbooks. Until today I'm still using the old pkg_info/_add/_create tools and skipped pkgng until today. Will the above procedure work fine too in the future? Why not keep the old methods unchanged in place as today? Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 7:23 AM, Daniel Nebdal dneb...@gmail.com wrote: On Thu, Feb 6, 2014 at 12:41 PM, Rick Miller vmil...@hostileadmin.com wrote: On Thu, Feb 6, 2014 at 2:59 AM, Big Lebowski spankthes...@gmail.com wrote: On Thu, Feb 6, 2014 at 7:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) I echo this sentiment, but I would like to take it a step further and say a certain version or greater. I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. Correct. My wish is the functionality be extended further to mean a certain version *or* newer, encompassing both features. Thus, allowing him to say port-1.1, while I say port-1.4 or newer or even port-1.0 or newer. -- Take care Rick Miller ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2/6/2014 13:27, Julian H. Stacey wrote: Michel Talon wrote: charset=us-ascii Junk mail format, not impressed. Use Ascii This is petty. i can only conclude, like Matthew that you are being absurd. Personal inuendo does not impress. While you may take this as an unnecessary attack, it doesn't mean that it's not true. In reality, I don't know how else I would describe your POV in a nicer way. Yes, everyone is entitled to an opinion, but you aren't free to be criticized for the one you publicly have. False. local.sqlite obstructs inspection by find grep text search tools. And several people said this was not something they ever had to do with years of experience. It also matches my experience. And the solution is swap out grep for pkg query. This looks like a red herring to me. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). hmm? I'm not following this. You aren't supposed to interact with the db directly, but though pkg queries. Moreover i have hard time believing one needs to dissect the package = system (beyond reading the=20 output of pkg info) to debug a port build. One surely needs some = ports/ is not just a plaything for package script addicts. Some use ports/ to make debug exclusively from sources. That doesn't require /var/db/ports though. --Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A Content-Transfer-Encoding: quoted-printable Send no junk ! petty class=3DApple-interchange-newline MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIbzCCA7Yw 50 lines un-necessary. petty. I didn't even see it. Either the mail list stripped it out or the mail client (thunderbird) obscured it. John ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2/6/2014 13:58, Rick Miller wrote: On Thu, Feb 6, 2014 at 7:23 AM, Daniel Nebdal dneb...@gmail.com wrote: I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. Correct. My wish is the functionality be extended further to mean a certain version *or* newer, encompassing both features. Thus, allowing him to say port-1.1, while I say port-1.4 or newer or even port-1.0 or newer. As an observer, all I can say is Don't get your hopes up on this one. Hundreds of ports are bumped with majority dependency changes for a reason. The tree is treated as an integrated entity, not 25,000 interchangeable parts. It would take major technology shift, something closer to what PC-BSD's pbi things do/did. Ports itself isn't geared for this. Maybe some kind of package archive could be used though, if pkg solvers could be made to handle such requests. Sounds like an extremely difficult request to me though. John ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 1:45 PM, Matthias Apitz g...@unixarea.de wrote: El día Thursday, February 06, 2014 a las 01:27:50PM +0100, Julian H. Stacey escribió: Michel Talon wrote: The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. Since many years I have always compiled my (i.e. the ports I need) from CVS or now SVN ports tree on some fast baquery maschine. After compiling I just did something like: # mkdir PKG # cd PKG # pkg_create -Rnb `cd /var/db/pkg ; ls -C1` and moved the resulting ~1500 packages to my laptops or smaller netbooks. Until today I'm still using the old pkg_info/_add/_create tools and skipped pkgng until today. Will the above procedure work fine too in the future? Why not keep the old methods unchanged in place as today? Thanks matthias The recommended way to do that is to set up poudriere. It's a different tool, but easy enough to work with, and it has certain benefits [1]. Obviously, that's neither a yes nor a no - and in short I don't know how pkg supports that specific use. [1] It's smarter about building in parallel, so it should be faster. It also handles compiling upgraded packages better - the logic is about the same as in portmaster/portupgrade, though building each port in a clean jail (with dependencies installed from the packages it has already created) reduces the risk of contamination from old versions on the host (typically automake scripts detecting some installed and not-yet upgraded library that's not set as a dependency ... at least that has happened to me a few times). It also creates a pkg repository with the packages, so if you have network access (nfs or http) you can use pkg to do installs or upgrades on the client machines (especially upgrades are very smooth like that). -- Daniel Nebdal ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. I really don't think so. Even with a single machine, poudriere literally saved my a.. pretty bottom several times breaking on implicit dependencies which would have popped up ages later with nasty and difficult to trace problems/errors. I think anybody who compiles from ports should _really_ use poudriere. I even think it should be strongly suggested in the handbook. (I'd be willing to write that up for that matter.) -- Christopher TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 9.2-STABLE #1 r256184: Thu Oct 10 19:12:54 CEST 2013 c...@dijkstra.cruwe.de:/usr/obj/usr/home/cjr/media/src/freebsd/base/stable/9/sys/GEN_WDTRACE Punctuation matters: Lets eat Grandma. or Lets eat, Grandma. - Punctuation saves lives. A panda eats shoots and leaves. or A panda eats, shoots, and leaves. - Punctuation teaches proper biology. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (RFC 1925) ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Am 2014-02-06 14:05, schrieb Daniel Nebdal: On Thu, Feb 6, 2014 at 1:45 PM, Matthias Apitz g...@unixarea.de wrote: El día Thursday, February 06, 2014 a las 01:27:50PM +0100, Julian H. Stacey escribió: Michel Talon wrote: The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. Since many years I have always compiled my (i.e. the ports I need) from CVS or now SVN ports tree on some fast baquery maschine. After compiling I just did something like: # mkdir PKG # cd PKG # pkg_create -Rnb `cd /var/db/pkg ; ls -C1` and moved the resulting ~1500 packages to my laptops or smaller netbooks. Until today I'm still using the old pkg_info/_add/_create tools and skipped pkgng until today. Will the above procedure work fine too in the future? Why not keep the old methods unchanged in place as today? Thanks matthias The recommended way to do that is to set up poudriere. It's a different tool, but easy enough to work with, and it has certain benefits [1]. Obviously, that's neither a yes nor a no - and in short I don't know how pkg supports that specific use. [1] It's smarter about building in parallel, so it should be faster. It also handles compiling upgraded packages better - the logic is about the same as in portmaster/portupgrade, though building each port in a clean jail (with dependencies installed from the packages it has already created) reduces the risk of contamination from old versions on the host (typically automake scripts detecting some installed and not-yet upgraded library that's not set as a dependency ... at least that has happened to me a few times). It also creates a pkg repository with the packages, so if you have network access (nfs or http) you can use pkg to do installs or upgrades on the client machines (especially upgrades are very smooth like that). And it supports devel/ccache out of the box. Just install ccache, create /var/cache/ccache and uncomment CCACHE_DIR=/var/cache/ccache in poudriere.conf The ports compile much faster with ccache enabled. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
El día Thursday, February 06, 2014 a las 02:36:30PM +0100, Christopher J. Ruwe escribió: On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. I really don't think so. Even with a single machine, poudriere literally saved my a.. pretty bottom several times breaking on implicit dependencies which would have popped up ages later with nasty and difficult to trace problems/errors. I think anybody who compiles from ports should _really_ use poudriere. I even think it should be strongly suggested in the handbook. (I'd be willing to write that up for that matter.) Please point me to the existing documentation. I don't see the string poudriere in our handbook. Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, February 6, 2014 4:27 am, Julian H. Stacey wrote: Michel Talon wrote: ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports = builds. As someone who has advocated the use of sqlite to replace the old = database in the filesystem several years before it has been implemented by the new package system, = i can only conclude, like Matthew that you are being absurd. Personal inuendo does not impress. The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. incredibly slow and using system resources in absurd ways. Sqlite obstructs nothing, False. local.sqlite obstructs inspection by find grep text search tools. you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). That's a good point, having the sqlite structures documented would be nice. I'll research to see what already exists, if nothing I'll put together some documentation in the next few days. I normally build from source, however I'm currently 'on the road' and wanted to update a laptop which has not been touched in about one year. Updating to 11.0-CURRENT was no problem, however converting the system to pkgng then trying to 'pkg upgrade' all the packages caused some headaches for me.. in the end it was _much_ easier to wipe /usr/local and /var/db/pkg and install everything fresh using pkg. Perhaps 'sounds scary' but not really. User settings/configuration is mostly in ~/ ... Doing it that way went very smooth and very quick. Overall I prefer pkgng to the previous pkg system. And storing information in sqlite database seems smart to me. I think maybe sqlite is used with yellowdog, but i've not looked hard at the inner mechanics of that system. I see your point about grep, I suppose grep doesn't work so well with sqlite databases. # grep fun local.sqlite Binary file local.sqlite matches The most painful trouble I've had with (any) package systems: r) a major upgrade to libraries which are dependencies in (many) other packages, ie png. s) introducing foreign software: building custom/or self-written/or 'manual' software into the same space as the packaged software (ie, /usr/local). t) updating a machine which has been 'neglected' for and extended period. pkgng is the most 'intuitive' and uncomplicated package system i've seen, i'm happy that so much effort has gone into creating a great product. Moreover i have hard time believing one needs to dissect the package = system (beyond reading the=20 output of pkg info) to debug a port build. One surely needs some = ports/ is not just a plaything for package script addicts. Some use ports/ to make debug exclusively from sources. -- Waitman Gobble San Jose California USA +1.510-830-7975 ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, 6 Feb 2014 15:49:24 +0100 Matthias Apitz g...@unixarea.de wrote: El día Thursday, February 06, 2014 a las 02:36:30PM +0100, Christopher J. Ruwe escribió: On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. I really don't think so. Even with a single machine, poudriere literally saved my a.. pretty bottom several times breaking on implicit dependencies which would have popped up ages later with nasty and difficult to trace problems/errors. I think anybody who compiles from ports should _really_ use poudriere. I even think it should be strongly suggested in the handbook. (I'd be willing to write that up for that matter.) Please point me to the existing documentation. I don't see the string poudriere in our handbook. Thx matthias I wrote it should be suggested, which means that I think it would be a good idea, not that it already happened. I do not understand how that could be misunderstood. Cheers, -- Christopher TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 9.2-STABLE #1 r256184: Thu Oct 10 19:12:54 CEST 2013 c...@dijkstra.cruwe.de:/usr/obj/usr/home/cjr/media/src/freebsd/base/stable/9/sys/GEN_WDTRACE Punctuation matters: Lets eat Grandma. or Lets eat, Grandma. - Punctuation saves lives. A panda eats shoots and leaves. or A panda eats, shoots, and leaves. - Punctuation teaches proper biology. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (RFC 1925) ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/02/2014 23:57, Kevin Oberman wrote: 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. When I first encountered the ports, way back in 1998 or so, I was completely mind-blown that something so fantastic could exist. Yes, it was revolutionary at the time and right where FreeBSD should be -- leading the rest of the world with great innovations. However, things have changed in the last 16 years. Development of the ports as a global concept has been resting on its laurels a bit, and the rest of the world has caught up, and indeed overtaken. Partly that was due to the mindset of seeing binary packages as a second-class thing; partly due to the old pkg_tools not providing the scope to implement innovative features; partly due to pkg_tools being part of the FreeBSD base, so impossible to update over reasonable timescales due to the requirement to support older RELEASE branches. pkg(8) addresses those problems, and I hope will do so for at least the next decade. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. I don't think it's possible to make a change of this magnitude without upsetting anyone. We have been getting a lot of feedack on the lines of 'Wow! This is great. When can we have feature XYZ?' to which we frequently have to reply that XYZ can't be implemented without breaking compatibility with pkg_tools. Like sub-packages. I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. One BIG one that I know is being worked is the capability to mix packages and ports effectively. If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com My experience with mixing ports and packages dates back to 2.2.5 and the disasters it created. Most of the problems were created by the ports tree and package builds not being syncronized. I switched to ports exclusively and have not had those problems again. If a mechanism existed to svn update a ports tree to the revision level of the package build I would probably try to use packages for most and limit building to those ports for which non-default OPTIONS were employed. For me, this is the feature that has always been missing. I recently switched to pkgng and while there is a learning curve I think it is more versatile and efficient than its predecessor. Thanks to all who are working to make things better. Randy ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 8:13 AM, Randy Pratt bsd-u...@embarqmail.com wrote: On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/02/2014 23:57, Kevin Oberman wrote: One BIG one that I know is being worked is the capability to mix packages and ports effectively. If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com My experience with mixing ports and packages dates back to 2.2.5 and the disasters it created. Most of the problems were created by the ports tree and package builds not being syncronized. I switched to ports exclusively and have not had those problems again. If a mechanism existed to svn update a ports tree to the revision level of the package build I would probably try to use packages for most and limit building to those ports for which non-default OPTIONS were employed. For me, this is the feature that has always been missing. I recently switched to pkgng and while there is a learning curve I think it is more versatile and efficient than its predecessor. Thanks to all who are working to make things better. That would be a *very* useful feature. To be able to query the remote pkg repo to get the svn revision number of the ports tree that was used to build the repo. Then you could pass that to svnup/svn to sync your local ports tree to the same revision. Then you could very easily mix/match local ports installs with remote pkg installs, as the versions for everything would match. Once the multi-repo features of pkg are up to snuff, perhaps adding a local repo would also help. Any software installed via the ports tree infrastructure would get tagged as part of the local repo. Then one could query the pkg database to get a list of software that came from the local repo, so we know which bits needs to be reinstalled/upgraded from the ports tree. Which, could easily tie into poudriere (or portmaster) for building the local ports en-masse. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
El día Thursday, February 06, 2014 a las 03:55:57PM +0100, Christopher J. Ruwe escribió: I think anybody who compiles from ports should _really_ use poudriere. I even think it should be strongly suggested in the handbook. (I'd be willing to write that up for that matter.) Please point me to the existing documentation. I don't see the string poudriere in our handbook. Thx matthias I wrote it should be suggested, which means that I think it would be a good idea, not that it already happened. I do not understand how that could be misunderstood. I have not misunderstood it. I only asked for any other existing documentation and that I do not even see the word/string in our handbook (which is ofc not your fault and which you want to improve). matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Le 6 févr. 2014 à 13:27, Julian H. Stacey a écrit : you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). First please excuse me, this message is posted via an Apple mail system. So how to interact with local.sqlite? niobe% sqlite3 local.sqlite SQLite version 3.8.2 2013-12-06 14:53:30 Enter .help for instructions Enter SQL statements terminated with a ; sqlite .tables annotation options pkg_script categories packages pkg_shlibs deps pkg_annotation pkg_shlibs_provided directories pkg_categories pkg_shlibs_required filespkg_directories pkg_users groups pkg_groups script licenses pkg_licenses scripts mtreepkg_option shlibs option pkg_option_default users option_desc pkg_option_desc sqlite .schema packages CREATE TABLE packages (id INTEGER PRIMARY KEY,origin TEXT UNIQUE NOT NULL,name TEXT NOT NULL,version TEXT NOT NULL,comment TEXT NOT NULL,desc TEXT NOT NULL,mtree_id INTEGER REFERENCES mtree(id) ON DELETE RESTRICT ON UPDATE CASCADE,message TEXT,arch TEXT NOT NULL,maintainer TEXT NOT NULL, www TEXT,prefix TEXT NOT NULL,flatsize INTEGER NOT NULL,automatic INTEGER NOT NULL,locked INTEGER NOT NULL DEFAULT 0,licenselogic INTEGER NOT NULL,time INTEGER, manifestdigest TEXT NULL, pkg_format_version INTEGER); CREATE INDEX pkg_digest_id ON packages(origin, manifestdigest); sqlite select name,version from packages limit 10; pkg|1.2.5 xproto|7.0.25 xextproto|7.2.1 xbitmaps|1.1.1 renderproto|0.11.1 libXdmcp|1.1.1 libXau|1.0.8 libxml2|2.8.0_3 libpthread-stubs|0.3_4 kbproto|1.0.6 and to replace grepping sqlite select name,version from packages where name like '%kde%' limit 10; kdehier4|1.1.1_1 kde4-wallpapers-freebsd|1.0 pam_kde|1.0 kde4-xdg-env|1.0.1 kde4-icons-oxygen|4.10.5 kde4-shared-mime-info|1.2 kdelibs|4.10.5_2 kde-wallpapers|4.10.5 kde-base-artwork|4.10.5 polkit-kde|0.99.1 sqlite .quit niobe% From this it is easy to experiment, and the full sqlite documentation is at: http://www.sqlite.org/lang.html -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2014-02-06 13:45, Matthias Apitz wrote:
El día Thursday, February 06, 2014 a las 01:27:50PM +0100, Julian H. Stacey
escribió:
Michel Talon wrote:
The old package system was total =
crap,
local.sqlite is also crap, breaks decades of accessibility by find grep
other text pipe / search tools.
Since many years I have always compiled my (i.e. the ports I need)
from CVS or now SVN ports tree on some fast baquery maschine. After
compiling I just did something like:
# mkdir PKG
# cd PKG
# pkg_create -Rnb `cd /var/db/pkg ; ls -C1`
and moved the resulting ~1500 packages to my laptops or smaller
netbooks. Until today I'm still using the old pkg_info/_add/_create
tools and skipped pkgng until today.
Will the above procedure work fine too in the future?
Why not keep the old methods unchanged in place as today?
Yes this is even possible.
$ mkdir $space/packages/All
$ pkg create -a -o $space/packages/All
$ pkg repo $space/packages/
Populate $space/packages via http(s), nfs or ftp
on your client:
$ mkdir -p $LOCALBASE/etc/pkg/repos
$ cat _EOL $LOCALBASE/etc/pkg/repos/mapitz.conf
mapitz: {
url: $proto://$baquery_maschine/$space/packages ,
enabled : true ,
mirror_type : none
}
_EOF
On your client run '$ pkg upgrade' and you are done.
However I suspect this method changes the checksum of the packages
every time you run '$ pkg create -a -o ...', but even then only
packages that really changed PORTREVISION ... will be updated
on your client.
The better way with a fast box is to run ports-mgmt/poudriere and
also have clean packages for your fast box.
A good starting point is to create a poudriere build and sync your
/var/db/ports to $LOCALBASE/etc/poudriere.d/($build)options/ and
copy your /etc/make.conf to $LOCALBASE/etc/poudriere.d/
Then use a list of ports (pkg_info -qoa| pkg info -qoa) and fire up
a build. The next time only changed ports are rebuild.
In the past I used tinderbox with the command
$ ./tc addBuildPortsQueueEntry -b ${BUILD}
to get consistent packages and had to wait a long time (*everything*
was located in a big 20GB RAM disk and/or on SSD), with poudriere most
everything is done on zfs in a part of the time and I guess with most
in a RAM disk even faster.
A good way to play with the new tools:
Setup a jail, install parts of your packages, convert them to pkg
packages and on a second jail install this ports.
--
olli
___
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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2014-02-06 19:17, Michel Talon wrote: Le 6 févr. 2014 à 13:27, Julian H. Stacey a écrit : you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). First please excuse me, this message is posted via an Apple mail system. So how to interact with local.sqlite? niobe% sqlite3 local.sqlite SQLite version 3.8.2 2013-12-06 14:53:30 Enter .help for instructions Enter SQL statements terminated with a ; sqlite .tables annotation options pkg_script categories packages pkg_shlibs deps pkg_annotation pkg_shlibs_provided directories pkg_categories pkg_shlibs_required filespkg_directories pkg_users groups pkg_groups script licenses pkg_licenses scripts mtreepkg_option shlibs option pkg_option_default users option_desc pkg_option_desc sqlite .schema packages CREATE TABLE packages (id INTEGER PRIMARY KEY,origin TEXT UNIQUE NOT NULL,name TEXT NOT NULL,version TEXT NOT NULL,comment TEXT NOT NULL,desc TEXT NOT NULL,mtree_id INTEGER REFERENCES mtree(id) ON DELETE RESTRICT ON UPDATE CASCADE,message TEXT,arch TEXT NOT NULL,maintainer TEXT NOT NULL, www TEXT,prefix TEXT NOT NULL,flatsize INTEGER NOT NULL,automatic INTEGER NOT NULL,locked INTEGER NOT NULL DEFAULT 0,licenselogic INTEGER NOT NULL,time INTEGER, manifestdigest TEXT NULL, pkg_format_version INTEGER); CREATE INDEX pkg_digest_id ON packages(origin, manifestdigest); sqlite select name,version from packages limit 10; pkg|1.2.5 xproto|7.0.25 xextproto|7.2.1 xbitmaps|1.1.1 renderproto|0.11.1 libXdmcp|1.1.1 libXau|1.0.8 libxml2|2.8.0_3 libpthread-stubs|0.3_4 kbproto|1.0.6 and to replace grepping sqlite select name,version from packages where name like '%kde%' limit 10; kdehier4|1.1.1_1 kde4-wallpapers-freebsd|1.0 pam_kde|1.0 kde4-xdg-env|1.0.1 kde4-icons-oxygen|4.10.5 kde4-shared-mime-info|1.2 kdelibs|4.10.5_2 kde-wallpapers|4.10.5 kde-base-artwork|4.10.5 polkit-kde|0.99.1 sqlite .quit niobe% From this it is easy to experiment, and the full sqlite documentation is at: http://www.sqlite.org/lang.html -- Michel Talon ta...@lpthe.jussieu.fr Before someone complains Michel's examples requires sqlite on the system, it even works without this way. $ pkg shell select name,version from packages limit 10; or $ echo 'select name,version from packages limit 10;' | pkg shell -- olli ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2/6/2014 17:13, Randy Pratt wrote: My experience with mixing ports and packages dates back to 2.2.5 and the disasters it created. Most of the problems were created by the ports tree and package builds not being syncronized. I switched to ports exclusively and have not had those problems again. If a mechanism existed to svn update a ports tree to the revision level of the package build I would probably try to use packages for most and limit building to those ports for which non-default OPTIONS were employed. For me, this is the feature that has always been missing. Well, there are now Quarterly branches. You should be able to use pkgs and interlace with built ports seamlessly as long as a quarterly branch is the source of both. But yes, using some random binary package set with the latest and greatest ports trunk is probably going to end badly at some point. John ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
W dniu 2014-02-06 14:04, John Marino pisze: On 2/6/2014 13:58, Rick Miller wrote: On Thu, Feb 6, 2014 at 7:23 AM, Daniel Nebdal dneb...@gmail.com wrote: I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. Correct. My wish is the functionality be extended further to mean a certain version *or* newer, encompassing both features. Thus, allowing him to say port-1.1, while I say port-1.4 or newer or even port-1.0 or newer. As an observer, all I can say is Don't get your hopes up on this one. Hundreds of ports are bumped with majority dependency changes for a reason. The tree is treated as an integrated entity, not 25,000 interchangeable parts. It would take major technology shift, something closer to what PC-BSD's pbi things do/did. Ports itself isn't geared for this. Maybe some kind of package archive could be used though, if pkg solvers could be made to handle such requests. Sounds like an extremely difficult request to me though. Gentoo's portage has this capability and it works quite well. I'd love to see it in FreeBSD. -- best regards, Lukasz Wasikowski ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 06/02/2014 12:45, Matthias Apitz wrote: Since many years I have always compiled my (i.e. the ports I need) from CVS or now SVN ports tree on some fast baquery maschine. After compiling I just did something like: # mkdir PKG # cd PKG # pkg_create -Rnb `cd /var/db/pkg ; ls -C1` and moved the resulting ~1500 packages to my laptops or smaller netbooks. Until today I'm still using the old pkg_info/_add/_create tools and skipped pkgng until today. Much the same except the pkgng command line is: pkg create -a There are fancier approaches to doing this sort of thing involving creating your own package repository (which is a lot easier than it sounds -- basically 'pkg repo /directory/where/your/pkgs/are' and then you can tell pkg to install from there by using a file:// URL for the packagesite. However, this is all optional and you can simply install what you want using 'pkg add'. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Matthew Seaman wrote: On 03/02/2014 21:24, Julian H. Stacey wrote: be beneficial in a very short amount of time. Even if you prefer to compile from source, =20 I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better.= =20 =20 you will still reap the benefits of the modern packaging system. =20 In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) =20 For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. You're being absurd. Immediately personal criticism is a poor way to start convincing. ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
- Original Message - From: Julian H. Stacey j...@berklix.com Immediately personal criticism is a poor way to start convincing. ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. We also maintain all our machines from in house built ports but I must say in the 10 years I've never used find / grep on /var/db/pkg to debug breaking port builds. Everyone works differently, so we may be unique here, but surely if the tools still exist to determine the issue e.g. sqlite queries, along side the clear advantages the new storage brings, I'm not sure what the issue is? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. As someone who has advocated the use of sqlite to replace the old database in the filesystem several years before it has been implemented by the new package system, i can only conclude, like Matthew that you are being absurd. The old package system was total crap, incredibly slow and using system resources in absurd ways. Sqlite obstructs nothing, you have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning obtuse find and grep options. Moreover i have hard time believing one needs to dissect the package system (beyond reading the output of pkg info) to debug a port build. One surely needs some knowledge of make, C, perhaps C++ which is vastly more difficult than figuring how to extract the content of the sqlite database. Finally i confess i am a package addict. Insisting that people use packages is the best way to ensure that the ports can indeed be built and that the result works. I have spent too many hours editing C files and makefiles in the past in the hope of getting something to build, now i want that it just works, like it does with the likes of Debian, etc. I am very grateful to Baptiste, Matthew and al. to the excellent job they have done, finally FreeBSD has a decent infrastructure for external software. The new package system is fast, efficient, and very importantly lists all the things it will do before doing them (like Debian apt), which allows to avoid ruining a working system, a very common occurrence in the old package system. So it does most of the things that i thought were necessary to come to parity with apt, and is light years ahead of the old system. -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Am 05.02.2014 23:02, schrieb Julian H. Stacey: Matthew Seaman wrote: On 03/02/2014 21:24, Julian H. Stacey wrote: be beneficial in a very short amount of time. Even if you prefer to compile from source, =20 I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better.= =20 =20 you will still reap the benefits of the modern packaging system. =20 In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) =20 For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. You're being absurd. Immediately personal criticism is a poor way to start convincing. ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. While I have wanted a few of the pkg options to be 100% compatible with the pkg_info options, I never felt the need to dig around in the package system innards other than to debug goofups that originated in the package system itself. Especially not to debug breaking port builds. portmaster has made things quite easy when dealing with source builds. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Wed, Feb 5, 2014 at 2:52 PM, Matthias Andree matthias.and...@gmx.dewrote: Am 05.02.2014 23:02, schrieb Julian H. Stacey: Matthew Seaman wrote: On 03/02/2014 21:24, Julian H. Stacey wrote: be beneficial in a very short amount of time. Even if you prefer to compile from source, =20 I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better.= =20 =20 you will still reap the benefits of the modern packaging system. =20 In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) =20 For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. You're being absurd. Immediately personal criticism is a poor way to start convincing. ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. While I have wanted a few of the pkg options to be 100% compatible with the pkg_info options, I never felt the need to dig around in the package system innards other than to debug goofups that originated in the package system itself. Especially not to debug breaking port builds. portmaster has made things quite easy when dealing with source builds. While I think this discussion is getting a bit emotional, I would like to point out a few things that some posters may not know. 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. 2. sqlite and mysql were not available at the time it was written. If there had been a solid, properly licensed RDBMS, I strongly suspect it would have been used. 3. While the system has evolved a great deal since it came to FreeBSD about 20 years ago (just a rough guess), it was really in need of an overhaul. Anyone who has used apt knows just how creaky is has become. (Not that I am crazy about apt. I find that it has some very unpleasant issues. I think pkgng is clearly superior.) 4. I will also miss the ASCII pkgdb. I will either live without it or write a small script to pull the relevant data out of the db and create a limited db that contains the data I need for my scripts that it. (I would only need to fill in a few fields and most scripts can be placed by pkg commands which are very flexible and powerful. pkg does a LOT more than the old pkg_ system. Of course, you will have to actually read limited documentation and the pkg help. (Far more complete than the last time I looked at the documentation.) I have long advocated for using the simplest, lowest overhead DB that will o the job and use flat ASCII DBs often. Too many developers seem to think that Oracle or is always the right answer for any DB and I'm sure Larry agrees. but really doing the ports/packages system write simply goes beyond what an ASCII DB is suited for. sqlite look like a very good fit for the job. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. On the whole, bapt and company have done a remarkable job that was really needed. It goes way beyond what any other package system I have seen can do. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 05/02/2014 23:57, Kevin Oberman wrote: 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. When I first encountered the ports, way back in 1998 or so, I was completely mind-blown that something so fantastic could exist. Yes, it was revolutionary at the time and right where FreeBSD should be -- leading the rest of the world with great innovations. However, things have changed in the last 16 years. Development of the ports as a global concept has been resting on its laurels a bit, and the rest of the world has caught up, and indeed overtaken. Partly that was due to the mindset of seeing binary packages as a second-class thing; partly due to the old pkg_tools not providing the scope to implement innovative features; partly due to pkg_tools being part of the FreeBSD base, so impossible to update over reasonable timescales due to the requirement to support older RELEASE branches. pkg(8) addresses those problems, and I hope will do so for at least the next decade. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. I don't think it's possible to make a change of this magnitude without upsetting anyone. We have been getting a lot of feedack on the lines of 'Wow! This is great. When can we have feature XYZ?' to which we frequently have to reply that XYZ can't be implemented without breaking compatibility with pkg_tools. Like sub-packages. I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk signature.asc Description: OpenPGP digital signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/02/2014 23:57, Kevin Oberman wrote: 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. When I first encountered the ports, way back in 1998 or so, I was completely mind-blown that something so fantastic could exist. Yes, it was revolutionary at the time and right where FreeBSD should be -- leading the rest of the world with great innovations. However, things have changed in the last 16 years. Development of the ports as a global concept has been resting on its laurels a bit, and the rest of the world has caught up, and indeed overtaken. Partly that was due to the mindset of seeing binary packages as a second-class thing; partly due to the old pkg_tools not providing the scope to implement innovative features; partly due to pkg_tools being part of the FreeBSD base, so impossible to update over reasonable timescales due to the requirement to support older RELEASE branches. pkg(8) addresses those problems, and I hope will do so for at least the next decade. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. I don't think it's possible to make a change of this magnitude without upsetting anyone. We have been getting a lot of feedack on the lines of 'Wow! This is great. When can we have feature XYZ?' to which we frequently have to reply that XYZ can't be implemented without breaking compatibility with pkg_tools. Like sub-packages. I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. One BIG one that I know is being worked is the capability to mix packages and ports effectively. If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
+--On 3 février 2014 19:23:12 -0800 Jeffrey Bouquet
jeffreybouq...@yahoo.com wrote:
| /# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name
| +CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep
| p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % yell || yell
|
| That pipe, corrected ( the working version includes an incrementing |
| head -NN | thru hundreds of p5 upgrades, 15-25 at a time,
| so easy completion of the upgrade with
| only a repeat with the up arrow and a minor edit ,) handily upgraded a
| /perl5/ subdirectory to
| the default on several installs.
So, you want a command going to upgrade all p5- ports that install files
that contain 5.12 in their path. I'm not sure what it's supposed to be
doing in the end, but it certainly won't help you going from one perl
version to the other, you're missing every port that installs perl modules
and is not named p5 something (like, say, net-snmp) and every port that
links with, say, libperl.so (like, say, vim)
If you want to do that with pkg, and do it that way, you can have a look at
what :
pkg query %ro lang/perl5.12
and feed that to portmaster. But the easiest way to do it would be to do,
say :
portmaster -o lang/perl5.16 lang/perl5.12
portmaster -r perl5-
Now, I would do :
pkg set -o perl5.12:perl5.16
pkg upgrade (possibly with -f depending on what it says without it)
But that's just me :-)
--
Mathieu Arnold
___
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-Announce] Time to bid farewell to the old pkg_ tools
There comes a time in the life cycle of just about every software package that it has bee re-evaluated, refreshed, deprecated or just retired. It is time that we bid farewell to the old pkg_* software that has been part of FreeBSD since the beginning, and has served us well. After years of development, testing, and playing, pkg(8) has become a suitable replacement. Pkg is the Next Generation package management tool for FreeBSD. It is the replacement for the current pkg_info/pkg_create/pkg_add tools that ports use to register local packages and which provide remote packages. Its main goals are to facilitate remote binary package upgrades. It also works with ports without remote binary packages. Pkg, combined with the quarterly release package sets, enables easy installation and safe upgrades for binary packages. Signed, binary packages are available for all supported FreeBSD releases on the i386 and amd64 platforms from pkg.freebsd.org. Additionally, for those compiling ports from source, pkg's new database format gives more fine-grained querying and management of installed software. New features on the drawing board, like automatic pkg-plist generation, sub-packages, creating multiple packages containing different parts of a port from one build process, and flavours, being able to ask for e.g. a webserver, without directly specifying a specific one, cannot be implemented in the old pkg_* tools and those plans are currently on hold. You are not obligated to switch to binary packages, if you still prefer to compile your own ports, it is a simple matter of installing ports-mgmt/pkg, run pkg2ng, add WITH_PKGNG=yes to your make.conf and use pkg action instead of pkg_action. You can read more about pkgng on the FreeBSD wiki, https://wiki.freebsd.org/pkgng. The decision has been made to allow the old pkg_* software to be EoL'd 6 months from now, at September 1, 2014 in all active FreeBSD branches. Please start testing pkg(8) in your test environments before taking it live, you will find the benefits of full binary updates for your ports to be beneficial in a very short amount of time. Even if you prefer to compile from source, you will still reap the benefits of the modern packaging system. http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/ ___ freebsd-ports-announce@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports-announce To unsubscribe, send any mail to freebsd-ports-announce-unsubscr...@freebsd.org
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
be beneficial in a very short amount of time. Even if you prefer to compile from source, I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better. you will still reap the benefits of the modern packaging system. In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 03/02/2014 21:24, Julian H. Stacey wrote: be beneficial in a very short amount of time. Even if you prefer to compile from source, I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better. you will still reap the benefits of the modern packaging system. In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. You're being absurd. local.sqlite is nothing like the Microsoft registry[*]. It's a database of all the files etc. that are managed through the ports system. No more, no less. All we have done is replace an unreliable collection of text files -- hard to keep consistent, impossible to update in an atomic fashion and woefully pessimal for certain quite legitimate queries -- with a RDBMS, which quite neatly disposes of those problems. No, it isn't ascii text which you can grep through. It's a set of relational tables, which you can query using SQL. And that is a deal more powerful in many ways than grep, but not so familiar to most; so we've provided a scripting interface in the form pf pkg-query(8). Do you complain because ZFS doesn't have it's configuration data in some ascii text files? How about procstat(8)? Or ld.so(1)/ldconfig(8)? Truth is, unix has always adopted a pragmatic approach to system data and stored it in whatever form would be most effective. In our case, we're pretty clear that a relational database is streaks ahead of a directory tree full of text files. Cheers, Matthew [*] Quite apart from anything else, a corrupt local.sqlite doesn't make one iota of difference to the operational effectiveness of your system. All it means is you've lost track of what port installed what file. -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
My first post that quotes good: Thunderbird rather than the webmail...
[As this one is about to be send, I see that it is a restate/duplicate
of the one
lost in a webmail glitch ... so apologies...]
On 02/03/14 14:38, Matthew Seaman wrote:
On 03/02/2014 21:24, Julian H. Stacey wrote:
be beneficial in a very short amount of time. Even if you prefer to
compile from source,
I use source, rarely if ever use packages, (except pkg_delete
to remove old broken dependencies). No opinion which scrips are better.
you will still reap the benefits of the modern
packaging system.
In 10.0 FreeBSD `reaped the benefit` of a default new horrible
registry that smells like Microsoft with quasi binary local.sqlite
needing special tools. (Yes I know there's an export function.)
For 2 decade we've poured scorn on Microsoft its opaque easily
damaged hard to access registry, lauded how with FreeBSD we can
examine manipulate repair our text based equivalent with any
number of personal choice text tools, now FreeSBD is burdened by
this horrible Microsoft style registry.
You're being absurd. local.sqlite is nothing like the Microsoft
registry[*]. It's a database of all the files etc. that are managed
through the ports system. No more, no less.
... our TEXT based ...
/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep
p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % yell || yell
That pipe, corrected ( the working version includes an incrementing |
head -NN | thru hundreds of p5 upgrades, 15-25 at a time,
so easy completion of the upgrade with
only a repeat with the up arrow and a minor edit ,) handily upgraded a
/perl5/ subdirectory to
the default on several installs.
All we have done is replace an unreliable collection of text files --
hard to keep consistent, impossible to update in an atomic fashion and
woefully pessimal for certain quite legitimate queries
A subset of the above pipe?
-- with a RDBMS,
Which a user may be expected to learn
which quite neatly disposes of those problems. No, it isn't ascii text
which you can grep through.
That here is a source of dismay... less creativity in pipes etc...
It's a set of relational tables, which you
can query using SQL.
That here is also a lessening of the fun.
And that is a deal more powerful in many ways than
grep, but not so familiar to most; so we've provided a scripting
interface in the form pf pkg-query(8).
Do you complain because ZFS doesn't have it's configuration data in some
ascii text files? How about procstat(8)? Or ld.so(1)/ldconfig(8)?
Truth is, unix has always adopted a pragmatic approach to system data
and stored it in whatever form would be most effective. In our case,
we're pretty clear that a relational database is streaks ahead of a
directory tree full of text files.
For those reluctant to switch over, maybe a concurrent
/usr/ports/ports-mgmt/pkg_legacy_tools
Maybe even concurrent installs [both package systems, ] , if they are
both tweaked to be co-existable, and each in
parallel improved over time. What if an urgent upgrade to a server
failed in one method, the
other could env -i in , this one env -i out, and the upgrade
proceed apace.
Or a command to test which method would work best of on a specific
upgrade, and that pkg system default (the
other backup) until the next switchover
Can't do that in [ insert other favorite operating system here ]...
Cheers,
Matthew
J. Bouquet
___
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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Mon, Feb 3, 2014 at 7:23 PM, Jeffrey Bouquet jeffreybouq...@yahoo.comwrote:
My first post that quotes good: Thunderbird rather than the webmail...
[As this one is about to be send, I see that it is a restate/duplicate of
the one
lost in a webmail glitch ... so apologies...]
On 02/03/14 14:38, Matthew Seaman wrote:
On 03/02/2014 21:24, Julian H. Stacey wrote:
be beneficial in a very short amount of time. Even if you prefer to
compile from source,
I use source, rarely if ever use packages, (except pkg_delete
to remove old broken dependencies). No opinion which scrips are better.
you will still reap the benefits of the modern
packaging system.
In 10.0 FreeBSD `reaped the benefit` of a default new horrible
registry that smells like Microsoft with quasi binary local.sqlite
needing special tools. (Yes I know there's an export function.)
For 2 decade we've poured scorn on Microsoft its opaque easily
damaged hard to access registry, lauded how with FreeBSD we can
examine manipulate repair our text based equivalent with any
number of personal choice text tools, now FreeSBD is burdened by
this horrible Microsoft style registry.
You're being absurd. local.sqlite is nothing like the Microsoft
registry[*]. It's a database of all the files etc. that are managed
through the ports system. No more, no less.
... our TEXT based ...
/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep p5
| sort | uniq | xargs -J % portmaster -d -B -P -i -g % yell || yell
That pipe, corrected ( the working version includes an incrementing | head
-NN | thru hundreds of p5 upgrades, 15-25 at a time,
so easy completion of the upgrade with
only a repeat with the up arrow and a minor edit ,) handily upgraded a
/perl5/ subdirectory to
the default on several installs.
All we have done is replace an unreliable collection of text files --
hard to keep consistent, impossible to update in an atomic fashion and
woefully pessimal for certain quite legitimate queries
A subset of the above pipe?
-- with a RDBMS,
Which a user may be expected to learn
which quite neatly disposes of those problems. No, it isn't ascii text
which you can grep through.
That here is a source of dismay... less creativity in pipes etc...
It's a set of relational tables, which you
can query using SQL.
That here is also a lessening of the fun.
And that is a deal more powerful in many ways than
grep, but not so familiar to most; so we've provided a scripting
interface in the form pf pkg-query(8).
Do you complain because ZFS doesn't have it's configuration data in some
ascii text files? How about procstat(8)? Or ld.so(1)/ldconfig(8)?
Truth is, unix has always adopted a pragmatic approach to system data
and stored it in whatever form would be most effective. In our case,
we're pretty clear that a relational database is streaks ahead of a
directory tree full of text files.
For those reluctant to switch over, maybe a concurrent
/usr/ports/ports-mgmt/pkg_legacy_tools
Maybe even concurrent installs [both package systems, ] , if they are both
tweaked to be co-existable, and each in
parallel improved over time. What if an urgent upgrade to a server failed
in one method, the
other could env -i in , this one env -i out, and the upgrade proceed
apace.
Or a command to test which method would work best of on a specific
upgrade, and that pkg system default (the
other backup) until the next switchover
Can't do that in [ insert other favorite operating system here ]...
Cheers,
Matthew
J. Bouquet
For all of us who have scripts already in use that take advantage of the
old pkg database, why not a tool to generate the old db from the new. All
of the data is in the new db... it only needs to be extracted and
formatted. Looks to be easy to do in Perl or Python. Could be written in C,
of course, but that seems like overkill. (And I am not volunteering to do
it as I can't make any promises on when I might get around to it.)
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 04/02/2014 03:23, Jeffrey Bouquet wrote:
/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep
p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % yell || yell
That pipe, corrected ( the working version includes an incrementing |
head -NN | thru hundreds of p5 upgrades, 15-25 at a time,
so easy completion of the upgrade with
only a repeat with the up arrow and a minor edit ,) handily upgraded a
/perl5/ subdirectory to
the default on several installs.
Which is a remarkably complicated equivalent to:
pkg set -o perl5.12:perl5.16
pkg install -fR perl5.16
I'm sure though if you really must have fun with pipelines that you
could start with:
pkg query %ro perl5
but working out how to divide that into chunks and feed into portmaster
is up to you.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
