jeffreybouquet at yahoo.com
Thu Aug 30 15:38:15 UTC 2012
--- On Thu, 8/30/12, Matt Burke <mattblists at icritical.com> wrote:
> From: Matt Burke <mattblists at icritical.com>
> Subject: Re: pkgng questions
> To: "Mark Felder" <feld at feld.me>
> Cc: ports at freebsd.org
> Date: Thursday, August 30, 2012, 7:44 AM
> On 08/30/12 13:01, Mark Felder
> > I think you're very confused about what pkgng is for.
> At this time, ports
> > are STILL the recommended way to install things and
> keep them up to date.
> Really? I think the last time I compiled X or a web browser
> (until using
> poudriere) was about 10 years ago.
I mix packages and ports here, heavily using zsh;/var/db/pkg/;pipes;portmaster and a thumbdrive(ftp) to other machines
> > Pkgng is the first step required for us to get a better
> package management
> > system so we can shift the community towards primarily
> using packages.
> I like packages - they save me compiling massive things on
> my desktop and
> they let me keep my servers running exactly the same
> software built from
> our CI setup. 'make package' is so quick and easy,
> it'd be hard to beat.
> So I thought I'd get a grip on pkgng before pkg_* disappears
> from base.
> I had a couple of questions I wanted to answer -
> 1) How easy does it make keeping my desktop (currently
> releng/9.1 built
> with dtrace) up-to-date
> 2) How much easier will it be to maintain production and
> testing servers?
> The answer has made me start downloading an OpenIndiana
> >> 2. Is there a list of ports like nvidia-driver,
> >> linux-f10-flashplugin, sampleicc (dependency of
> libreoffice!) which aren't
> >> in pkgng?
> > Everything can be built into the pkgng format except a
> few ports that need
> > workarounds. There's a list on the wiki.
> > http://wiki.freebsd.org/pkgng
> > Go to the bottom "Known Failures" section.
> I don't see any of the examples I gave listed, apart from
> >> 3. How do I force pkg to install/upgrade a single
> package, regardless of
> >> dependencies being out of date?
> > You should never try to do this anyway; you'll end up
> with packages built
> > against the wrong versions of libraries.
> You're suggesting that I should upgrade an entire machine
> which may have
> proven itself over a period of years to be perfectly stable,
> just because I
> need a small utility which really doesn't care about the man
> page typo
> which caused gettext-0.1.2_3 to change to gettext-0.1.2_4?
Notable here, things which depend upon firefox; gcc46; ...
> >> 4. How do I get poudiere to build against a local
> src/obj tree, or a zfs
> >> snapshot of a pre-built jail, instead of
> > The poudriere man page has all the instructions needed
> to create jails of
> > any release version to be used for building packages.
> No, the man page doesn't mention anything about specifying
> where to pull
> the distribution from, only what method of access to use.
> > You don't do it this way. You build everything on your
> poudriere server and
> > push all of your packages to the client. You do this
> every single time. If
> > you decide you want a new package on your client, you
> build it on your
> > poudriere server and have your client request it. If
> you're using
> > poudriere/pkgng, your clients should NEVER be compiling
> ports or installing
> > packages outside of what your poudriere server is
> providing. Poudriere is
> > giving you a "cleanroom" environment where it can
> guarantee that all the
> > packages and their required packages/libraries are
> > Pkgng doesn't require ZFS -- poudriere does. Your
> clients should never have
> > poudriere.
> I am confused. If pkg_* are removed, how is a person with a
> single desktop
> machine (worst case, a netbook) expected to operate if they
> need a specific
> port build? Are they to spend a week compiling 1000+ ports
> themselves in a
> poudriere VM?
> Or is the flexibility of FreeBSD ports just not deemed to be
> useful to the
> end user (or person unable to provide a dedicated any more?
I am also perplexed; (unconvinced; ignorant...).. Waiting for
a more comprehensive comparison to what exists now. And I've
read the documentation thoroughly, but not enough times to
fully comprehend all the strata...
> >> 8. Is there a pkgng equivalent of 'ls -lt
> /var/db/pkg' without firing up
> >> sqlite?
> > Are you looking for the date column (not sure why
> that's useful as it can
> > change due to many things)? Doesn't "pkg info -a"
> 'ls -lt /var/db/pkg' will show me what packages were
> installed sorted by
> day. It is very useful on servers which aren't routinely
> upgraded to the
> latest and greatest untested versions
/var/db/pkg/ here is also indispensable, ( which I
detailed precisely why in a message to the
freebsd-current list, this month... ) Until I'm forced to
upgrade to /pkg/ instead (I've workarounds and
maybe a PR or two (feature req.) thought out...), I see this as a fork of the package registration API to
something less useful to some, more useful to others (those using less
ports than the number I've installed, maybe. )
> >> 9. Why didn't pkg upgrade tell me it replaced my
> custom-built packages? I'd
> >> have liked for it to not break stuff when
> /var/db/ports/*/options differed
> >> from the options I can see pkgng keeps in its
> > Your poudriere server can use you preferred options
> when it builds
> > packages. Check the man page.
> pkg2ng doesn't tell you that you're about to need another
> $ man pkg2ng
> No manual entry for pkg2ng
> > Long story short: poudriere is a tool for you to build
> your OWN private
> > package repositories (which is really handy!).
> It is handy IF you have the resources to maintain a
> poudriere machine.
> It is handy IF you really enjoy waiting for x.org and web
> browsers to compile
> It is NOT handy if you just want to build one package to be
> built with
> different options. In fact it makes a mockery of FreeBSD's
> ease of use.
> > Pkgng is just the first step towards a large goal of
> greatly improving
> > the enduser experience with FreeBSD.
> By "improving", you mean "removing flexibility from"?
> > I don't believe pkgng is default on any release yet, so
> > shouldn't be using public pkgng repositories for
> anything but testing. You
> > should either be running your own poudriere server or
> you should just be
> > using the new pkgng format with ports.
> Wait, you said "If you're using poudriere/pkgng, your
> clients should NEVER
> be compiling ports or installing packages outside of what
> your poudriere
> server is providing"
> So what is it?
> The information contained in this message is confidential
> and intended for the addressee only. If you have received
> this message in error, or there are any problems with its
> content, please contact the sender.
> iCritical is a trading name of Critical Software Ltd.
> Registered in England: 04909220.
> Registered Office: IC2, Keele Science Park, Keele,
> Staffordshire, ST5 5NH.
> This message has been scanned for security threats by
> iCritical. www.icritical.com
> freebsd-ports at freebsd.org
> mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
I find this a very difficult topic , sort of like debating
whether FreeBSD should be forked to a FreeBSD-pc/bsd hybrid and
no legacy version; complicated by the many subtopics in the
ongoing discussion. It may be that I'd like the hybrid result
better in the long run (more upstream repositories?) , but those that are certain pkg will be
the default in a future version have not made obvious any
recourse (or explanation ) for those (like myself) who prefer to have the choice
available, at least for the minority or majority of FreeBSD users
who mix packages and ports as a matter of course.
 clearer examples of those who, for instance, should/should not
install other ports additionally to /pkg/, in the manner of a
flowchart incorporating all/most use cases... (usb boot? pxe? ...)
 Newbie or something similar...
More information about the freebsd-questions