On Thu, 30 Aug 2012 09:44:42 -0500, Matt Burke <mattbli...@icritical.com>
wrote:
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.
Yes, but an example I gave in another thread reply is PHP. You can't
pkg_install PHP right now and get Apache support. You HAVE to compile. The
new pkg format is a step towards sub-packages so we can have a better
public package repository that can fill 99% of everyone's needs.
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
It should be no different -- perhaps easier even.
2) How much easier will it be to maintain production and testing servers?
It will be no different. In fact, if you have a lot of servers but you
have consistent, customized options across them all it will be EASIER to
deploy and update packages with pkgng and poudriere.
The answer has made me start downloading an OpenIndiana iso.
I don't see what OpenIndiana gains you...?
I don't see any of the examples I gave listed, apart from nvidia-driver
Because the examples you gave have no issues with pkgng. If they're not in
the public repository that's not a pkgng problem, it's a repository
problem. You should be using pkg_* until the ports@ team has stated that
the public pkgng repository is the one everyone should be using. pkgng 1.0
has just been announced, but that just means the tool has reached
maturity, not the package management of FreeBSD has instantly changed to
pkgng.
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?
I'm not sure how you've come to this conclusion? If you have a poudriere
server building packages and you only want to install one new utility,
just tell poudriere to build only that utility and not build your entire
list of packages. Yes, if that utility depends on gettext you'll find
poudriere upgrading gettext and everything that depends on it. That's what
poudriere does -- make sure that everything is built against whatever is
current in the ports tree provided. But again, we're getting into the
realm of mixing ports and packages which you should always take great
caution when doing. You'll still be able to do that with pkgng.
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.
poudriere jail -c -v 8.3-RELEASE -a amd64 -j 8stable-amd64
This builds a jail from 8.3-RELEASE. If you want to update it to 8-STABLE
build the 8-STABLE world and "make installworld
DESTDIR=/path/to/poudriere/jail/named/8stable-amd64"
Does that help?
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?
Do not change what you are currently doing. Keep using pkg_* until the
pkgng repositories are deemed to be the official package repositories of
FreeBSD. If you really know what you're doing, you can still mix ports and
packages with pkgng. Later when we have subpackages you probably will
never need to do a "specific port build" because you want different
options.
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
There has been discussion to backport creation /var/db/pkg entries and
make it readonly. I understand your need because I use that too sometimes.
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...
You should know by now that mixing ports and packages is dangerous. And
we've sort of covered earlier what's going on here.
I'm cutting the rest below this because the answer is redundant: pkgng is
the new package tool and package format. It's compatible with everything
you were doing before. It has much better features, dependency tracking,
and it's very fast. It's going to be followed by some fantastic upgrades
to the package management ecosystem that should eliminate the need for
compiling custom packages for the majority of the users out there. Please,
don't be afraid of it. Just be patient and wait for bapt and friends to
tell everyone to stop using the old package repositories before you make
any complaints about the current pkgng packages (or lack thereof).
FreeBSD's ports and package system has been incredibly flexible -- I
agree. The goal is to preserve every bit of flexibility while at the same
time providing a better public package repository. If you've found a
serious bug that is breaking your ability to do something please contact
the ports team and let them know -- they don't want to alienate power
users.
It really just sounds to me like you jumped on the pkgng train too soon
without realizing you were beta testing. Pkgng+poudriere is awesome and
solves all sorts of problems I've had with the old system. I'm sure you'll
see the value in some of these new changes soon enough :-)
_______________________________________________
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"
