Re: CFT: FreeBSD Package Base

On Mon, Apr 29, 2019 at 9:55 AM Emmanuel Vadot <manu_at_bidouilliste.com>
wrote:

> On Mon, 29 Apr 2019 09:25:05 -0400
> Kris Moore <kris_at_ixsystems.com> wrote:
>
> > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot <manu_at_bidouilliste.com>
> > wrote:
> >
> > >
> > >  Hi Kris,
> > >
> > > On Sun, 28 Apr 2019 15:52:21 -0400
> > > <kris_at_ixsystems.com> wrote:
> > >
> > > > FreeBSD Community,
> > > >
> > > >
> > > >
> > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and
> > > 13-current
> > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images
> > > which
> > > > will allow users to perform all updating via the 'pkg' command
> directly.
> > > > Rather than trying to answer all questions in this announcement,
> we've
> > > > created a FAQ page with more details. Please refer to this page, and
> let
> > > us
> > > > know if you have additional questions that we can include on that
> page
> > > going
> > > > forward.
> > > >
> > >
> > >  While I appreciate the effort I have some doubt about your
> > > "re-implementation" of pkgbase. I don't see any improvement compared to
> > > what is in base currently, I even see downside of your implementation.
> > >
> > >  - How do you plan with the need of updating kernel first, reboot and
> > > updating the rest of the userland after ? (Needed for major and minor
> > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and
> > > -HEAD branch). This is still a problem with the base pkgbase.
> > >
> >
> > We've written our own tool "sysutils/sysup" in GO which handles this. It
> > performs updates using Boot-Environments to ensure that kernel/world are
> > updated at same time.
> >
>
>  Which could never be imported into FreeBSD.
>

Not suggesting it should be. Just information on how we solved that problem
in our own appliance / platforms. For FreeBSD it would need some tooling
still to handle this style of updating, regardless of which pkg base is
used.

And for what it's worth, FreeBSD is all the poorer for not being able to
bring modern language based tools into the base. Personally I'm hoping the
shift to base-packages makes this a moot point since the idea of 'what is
base' can be diluted to just a manifest of what gets installed out of box.
Just my 2C on the matter though :)


>
> >
> >
> > >  - This is even worse because you are using the same repository for
> > > base and pkg so if a user pkg update and both kernel and pkg(8) needs
> > > to be updated and pkg use a new syscall or capsicum thing it will be
> > > updated first and couldn't proceed with the rest of the update (this is
> > > a supposition, I haven't personally tested).
> > >
> >
> > See above.
>

You can selectively update os/kernel and reboot before doing rest.


> >
> >
> > >  - It seems that multiple kernels isn't supported in your
> > > implementation, this is already supported in pkgbase but still need
> > > some love. This is an important point as it will allow user to choose
> > > easily the kernel that they want to use and will also allow us
> > > developper to push kernels with new features to help testing.
> > >
> >
> > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll
> get
> > the Witness-enabled kernel installed alongside non-debugging one.
>
>  Mhm no, the kernel-debug packages only add the debug file
> in /usr/lib/debug/boot/
>  I'm talking about installing multiple kernels in //
> (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like
> describe here :
>
> https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues
> in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point.
>
>
Incorrect, os/kernel-debug installs /boot/kernel-debug which is (on
13-CURRENT) the Witness enabled kernel. os/kernel-debug-symbols are the
/usr/lib/debug bits.


>
> > >
> > >  I think that the only advantage that your solution offers is that if
> > > we remove a componant of base (rcmds for example in 12-CURRENT) those
> > > files would be removed as they are in the userland-base package while
> > > for pkgbase the FreeBSD-rcmd package will be deleted in the repo and
> > > will not be deleted in the user computer.
> > >
> >
> >
> > Correct, this is one of the things which prompted us to go this
> direction.
> > Being able to handle crazy mixed WITH/WITHOUT flags was important to us,
> > current pkg base did not handle that so gracefully.
>
>  Can you give me more info on this ? What where the WITH/WITHOUT flags
> that causes problems ?
>


I may have to pick Miwi's brain on this, but I believe some of the issues
we saw were when introducing flags such as WITHOUT_RADIUS. Additionally
there is a runtime problem to solve. I.E. if you change flags mid-stream,
and user updates, there was no clean way on pkg-side to remove those
already installed granular packages. Not without external tooling anyway.



>
> --
> Emmanuel Vadot <manu_at_bidouilliste.com> <manu_at_freebsd.org>
>