pkgng questions

[Jeffrey Bouquet]

--- 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
> wrote:
> > 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
> iso.
> 
> 
> 
> >> 2. Is there a list of ports like nvidia-driver,
> nspluginwrapper,
> >> 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
> nvidia-driver
> 
> 
> >> 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
> 9.0-RELEASE?
> > 
> > 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
> sane.
> 
> > 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"
> suffice?
> 
> '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
> metadata...
> > 
> > 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
> machine

Seconded.

> 
> $ 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.
> 

Seconded. 

> 
> > 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"?

Seconded. 

> 
> 
> > I don't believe pkgng is default on any release yet, so
> you
> > 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
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
> 

I find this a very difficult topic [2], 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 [1]) 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.
[1] 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? ...)
[2] Newbie or something similar...  


J. Bouquet