On (19/04/2016 13:36), Adrian Chadd wrote:
> It's cool. I have positive and negative reactions, and I'm totally
> happy to let people try it out at a larger scale and learn from
> mistakes.
> Because, honestly - fuck it, we've been behind for too long. We need
> more mature tools and knowledge with this.
> The irony of course is the people rolling out docker are doing it
> after finding that OS packages aren't the best granularity, but
> "whatever the package systems in the software stack we're using, and
> then tar the whole mess up and distribute it" method. Kinda like
> FreeBSD....

It's close to the way I see the packaging issue..

Our use case may not be the most common one -- we sell software in 2U
form factor (hardware included) :) Once in a while one has to roll
updates for the base system as well as our firmware. Packages has never
been much of a help but rather another obstacle to deal with for me
personally and I bet for our support as well. The thing I care about
most is to have the same base system for all customers who have
installed updates. It's really hard to troubleshoot assuming that some
package updates might have failed for a customer. Distributing images
comes very handy in this situation.

Although packages are useful in development:
- Being able to install complete development environment into the base
  system (debug symbols, compilers).
- Installing updates on *dev* machines. Which I'd rather avoid for
  release builds. By having packages for both release and dev one would
  need to have release and dev package repositories.  Much like
  stable/unstable repositories in many linux distros. Revision control
  systems tend to be much better at this at much lower cost.  Being able
  to do 'make happyworld whatever' out of the box on dev machine as well
  as installing packages built by CI is huge improvement comparing to
  packaging as it's often done in linux.
- Keeping any package metadata up to date in dev is painful (version
  bump in most cases).

How do we intend to do base system package versioning? Is it going to be
the same version for all packages or do we intend to bump versions in
individual Makefiles? Sorry if it has been discussed already, I must
have missed it.

IMHO >700 hardly makes any sense. I see no point in having individual
package for each binary under /bin and .so. I'd rather tweak a couple
Makefiles to remove stuff I don't need. WITH_* options in src.conf could
be a great list of packages to start with. Having -doc and -include in
separate packages would be appreciated as well.
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to