Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule

From: Michael Ranner <michael_at_ranner.eu>
Date: Fri, 13 Jul 2012 10:16:04 +0200
Am 13.07.12 01:10, schrieb Doug Barton:
> On 07/12/2012 03:02 PM, Baptiste Daroussin wrote:
>> On Thu, Jul 12, 2012 at 11:48:41AM -0700, Doug Barton wrote:
>>> I do not mean this e-mail to be in any way critical. I was told after
>>> the new OPTIONS framework discussion that I should have asked questions
>>> before the change, so I'm asking these questions now; in a genuine
>>> attempt to get information.
>>>
>>> On 07/12/2012 03:01 AM, Baptiste Daroussin wrote:
>>>
>>> In the time that you have been working on this project I have asked
>>> numerous times for you(pl.) to answer the following questions:
>>>
>>> 1. What are the goals for pkg?
>> The why part of this mail should reply this question, no?
> Well clearly not, because if it did I wouldn't keep asking the same
> questions over and over again. :)
>
>> Anyway the goal is to have a decent package manager, providing modern features:
>> repositories, decent dependency tracking, decent reverse dependency tracking,
>> managing upgrade correctly (I'll explain this more later), provide a decent
>> library for third party tools (desktop integration via PackageKit for example)
> I don't know what "decent" means. I don't know what "modern features"
> means (beyond the buzzwords that you've included).
>
>> Providing easy package management for enterprise
> Having set up package management systems for enterprises before, *this*
> is actually a big-picture goal that I have a lot of sympathy for. But
> again, what's missing is *details* about here is what large enterprises
> need to make things work for them, here's why the existing tools don't
> meet those needs, and here is how pkg does meet them.
>
>> (who never got problems
>> managing packages on a large set of freebsd servers, and how complicated it is
>> on FreeBSD to have automated reliable puppet,salt,chef,cfengine like tools)
>> One of the proof of this problem is how fast people integrated pkgng in those
>> tools.
> This gets to the heart of my biggest fear regarding this whole project.
> It's new, it's shiny, and it looks like forward progress is being made.
> Thus, it's attracted a lot of attention, input, time, etc. Heck, it may
> even BE forward progress, but I don't know how to measure that because I
> don't know what the goals of the project are. Thus, my fear is that
> without *details* about what the project is, and what it's trying to
> accomplish, we're going to put an exponentially larger volume of work
> into the transition and end up no closer to the goal of having a mature
> package management system.
>
> And just to be clear, I am *not* saying that "pkg sucks" or that it's
> bad, or wrong, or anything else. I'm saying that I don't know how to
> evaluate it, because you haven't given us a criteria by which to measure
> it.
>
> So what's the problem? We *desperately* need a better system for ports
> and packages. We only have so many person-hours we can devote to making
> that happen. If we spend all of them on pkg, and it ends up not helping
> us enough, we've burnt out our volunteers for no good reason.

I am using pkg_* tools since '94 and I am using portmaster for ports/pkg 
maintainance for years: pkg_* tools are a pain in the ass in the view of 
an administrator. I use it only and partly on fresh installs and doing 
further security auditing with portaudit and upgrading with portmaster - 
most time upgrading from source. But only, because its simply not 
possible the same way with the pkg_* tools.

Because I manage dozens of installation across Europe, buildind and 
updating from ports will be more and more time consuming. portmaster is 
really a great tool to take control of this lack of features in pkg_* 
tools , but I am running out of time more and more.

I was also a bit concerned and reserved to pkgng. But I am also in 
contact with some local FreeBSD ports committers and one of them (decke) 
told me some stories about pkgng and poudriere. I saw the talk from Beat 
Gätzi (beat) at EU BSD Day 2012 about pkgng and was I see was really 
nice and made me courious. So I tried to setup a small build environment 
with poudriere and pkgng to evaluate an substitution for my traditional 
pkg/port security upgrading with portmaster.

Finally I think, I can complete replace portmaster with pkgng, poudriere 
and an self build and maintained pkg repository. This will save a huge 
amount of time in future and allow to roll out security updates for 
packages really fast and easy.

So pkgng is not designed as a replacement for portmaster, but now it 
allows me to work without it on most of my installations.

I know almost any of the "Linux Enterprise" package management features, 
pkg_* tools a far away from this kind of functionality, even with the 
support of the great portmaster tool. Bug pkgng improves much more.

Its a very complex problematic. Yes documentation is not so good as it 
could be. But I saw the talks from beat in live, saw the screencasts 
from bapt on Youtube and finally I tried it on my own. It was necessary 
to try it out and see it, feel it, smell and taste it.

I think its good work from admin and enterprise point of view.

Doug has written portmaster and integrated package handeling, which I 
only use rarely on my old desktop. Why was this handling integrated in 
portmaster and not in pkg_* tools?

I know its something unkown and new and I had also my problems with the 
idea of pkgng for the first time (why reinventing the wheel...) - but I 
tried it out and it works really really well.

My opinion after 18 years of FreeBSD administration.

Regards,
Michael

-- 
Mit freundlichen Grüßen

Ing. Michael Ranner

GSM:  +43 676 4155044
Mail: michael_at_ranner.eu
WWW:  http://www.azedo.at/
Received on Fri Jul 13 2012 - 06:16:28 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC