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.Received on Wed Apr 27 2016 - 17:16:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:04 UTC