Re: CFT: FreeBSD Package Base

From: George Michaelson <ggm_at_algebras.org>
Date: Thu, 2 May 2019 09:21:34 +1000
The current state of this looks logical: its the bare minimum to
represent the .tgz which we recognized from install menu choices,
which minimises any real SAT solver dependency load, because these are
not cross-dependant in any strong sense.

The goal surely would be to prove this works and test. Then, we can
move to the state I think I want, and I presume by extension everyone
else wants: Sets which are small enough they expose risk of cross
dependency, but once a SAT solver reconciles them, you have ONLY the
minimum needed to do your job. So a "tiny" FreeBSD could be back under
4MB (hypothetically) because it was /rescue and the kernel, and if you
needed /usr/share you loaded a pkg.

-G

On Wed, May 1, 2019 at 7:33 PM Miroslav Lachman <000.fbsd_at_quip.cz> wrote:
>
> Cy Schubert wrote on 2019/05/01 05:56:
> > In message <292eadc6-3662-ec43-1175-53fc252487bd_at_quip.cz>, Miroslav
> > Lachman wri
> > tes:
> >> David Chisnall wrote on 2019/04/30 10:22:
> >>> On 29/04/2019 21:12, Joe Maloney wrote:
> >>>> With CFT version you chose to build, and package individual components
> >>>> such as sendmail with a port option.  That does entirely solve the
> >>>> problem of being able to reinstall sendmail after the fact without a
> >>>> rebuild of the userland (base) port but perhaps base flavors could
> >>>> solve that problem assuming flavors could extend beyond python.
> >>>
> >>> This sounds very much like local optimisation. It's now easy to create a
> >>> custom base image.  Great.  But how do I express dependencies in ports
> >>> on a specific base configuration? This is easy if I depend on a specific
> >>> base package, but how does this work in your model?  For example, if I
> >>> have a package that depends on a library that is an optional part of the
> >>> base system, how do I express that pkg needs to either refuse to install
> >>> it, or install a userland pkg that includes that library in place of my
> >>> existing version as part of the install process?
> >>>
> >>> More importantly for the container use case, if I want to take a
> >>> completely empty jail and do pkg ins nginx (for example), what does the
> >>> maintainer of the nginx port need to do to express the minimum set of
> >>> the base system that needs to be installed to allow nginx to work?
> >>>
> >>> One of the goals for the pkg base concept was to allow this kind of use
> >>> case, easily creating a minimal environment required to run a single
> >>> service. With a monolithic base package set, you're going to need some
> >>> mechanism other than packages to express the specific base subset
> >>> package that you need and I think that you need to justify why this
> >>> mechanism is better than using small individual packages.
> >>
> >> Will it not be maintainer's nightmare to take care of all the
> >> dependencies on the base packages for each port we have in the ports tree?
> >
> > No more than it is today. Remember, people have been doing this sort of
> > thing for decades. If the folks at Red Hat, Oracle (formerly Sun), and
> > IBM can do it, I'm sure we can too. The dependency lists will be
> > longer. We may require dependency lists that allow the choice of one of
> > many prereqs or coreqs.
>
> They are experts and they are paid for their work. I am not. I am
> maintaining a few packages and the reality is I don't know what they
> need in base. Till these days I don't care about this kind of
> dependency. I am not system developer or programmer and I think there
> are more than just me who see this as a kind of problem.
> So in this case, pkg base gives me nothing but more work on those packages.
>
> Miroslav Lachman
> _______________________________________________
> freebsd-stable_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe_at_freebsd.org"
Received on Wed May 01 2019 - 21:21:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC