FreeBSD problems and preliminary ways to solve

[Baptiste Daroussin]

Hi,

My reply only concerns package/ports management.
Most of what you are expecting from the ports tree is coming soon (new 
option framework) and most of what you are expecting from binary 
packages will be done with pkgng.

Just have a look https://github.com/pkgng/pkgng for pkgng it is still 
experimental but works quite well :).

>
>> 3. Ports and packages.
>
> What was the main problems with large-scale installations of FreeBSD 
> in
> that businesses? In short, that binary packages are not equal in 
> rights
> to ports, and that complicates things (i.e. requires too much work) 
> when
> one have many (> 10) servers. This was listed to me as:
>
> 2) Package name is dependent on options, so packages with another 
> opts
>    don't work well when dependencies are rebuilt.

They will with pkgng.

>
> 3) Conflicts: no way to have apache13 and apache22 the same time.
>

This is not a problem of the infrastructure nor of the package tools, 
this has to deal with the said ports.
I'm pretty sure if you come with a path to solve this (for example 
avoid file conflicts)

> 4) No dependence on base system. You may cut out something, recompile
>    world, deploy it on cluster and just then see that some packages 
> are
>    now don't work.
>
> 6) Update problems. The version is just coded into name of package, 
> and
>    dependencies are on the entire name, so there are situations when
>    install/upgrade of just one package may require rebuild 3/4 of all
>    pkgs. You cannot easiy modify installed package without editing 
> pkgdb
>    manually. It is impossible to upgrade/replace package by out of 
> the
>    box tools.
>

This will be solve with pkgng

> 8) There is no -STABLE supported branches in ports.
>
> All of this could be avoided (they know about tinderbox etc.) but 
> just
> requires too much work, for their basic tasks like automated upgrade 
> of
> entire system & packages or reinstall of needed packages.
>
> That's problems. Next, possible (gathered) solutions.
>
> It is obvious that current packages are not first-class citizens, in
> comparison with ports. They want ba able to run most machines without
> a compiling at all (BTW, our desktop users need the same), but 
> setting
> build farms when there are many machine roles is hard.
>
> So packages need to be "equal in rights" in ports. The ports can have
> things like this:
>
>   .if ${OSVERSION} < 700104 || ${OSVERSION} >= 900000
>
> or this:
>
>   LIB_DEPENDS+= profiler.1:${PORTSDIR}/devel/google-perftools
>
> but packages are not so flexible, all you have is:
>
>   @pkgdep perl-5.8.9_2
>
> skv@ proposed the following changes:
>
>  * OPTIONS need radio-buttons (e.g. only one of MySQL, PostgreSQL,
>    SQLite) and dialog(1) supports it.
>

This is coming soon to the ports tree, time to do more testings

>  * Options must be included and installed to /var/db/ports/*/options
>    (this will allow to rebuild installed binary pkg as port)
>

This could be a good idea :) I'll keep it for pkgng

>  * Info about options must be included to /var/db/pkg/*/+CONTENTS 
> like:
>
>      @option WITH_SSL
>      @option WITHOUT_DEBUG
>

There is an equivalent of this in pkgng.

>  * (internal) move away from CVS, rebalance to category-subcategory.
>
> These ideas in later discussion evolved to another additions. Let say 
> we
> are able to use multiple repositories, where "repository" is a 
> variant
> of /usr/ports tree and packages built from it. Then, each port allows 
> to
> build several packages from it, with different options. Now, if we 
> have
> a port called "softina" and user does
>
>   pkg_add -r softina
>
> then dependency search must be made given needed options. So @pkgdep
> consists just of "softina" and versions like ">=1.1" and options. 
> Also,
> if packages are equal in rights to ports, they need 
> integrity/security
> check. So, package file name is now like:
>
>   softina-1.2.3_1:repo.id:1312929890.tbz    # chars allowed by 
> windows
>

pkgng have an experimental multi repository support, even if we focus 
on a clean single repository support.

> Next, skv@ said about radio-buttons, and thay also have it, in two
> favors: first with one from group always set, second allowin all 
> clear:
>   "Exactly one of the following gecko options is required"
>   "At most one of the following database options may be selected"
>
>   | PKG_OPTIONS_REQUIRED_GROUPS is like PKG_OPTIONS_OPTIONAL_GROUPS, 
> but
>   | building the packages will fail if no option from the group is
>   | selected. PKG_OPTIONS_NONEMPTY_SETS is a list of names of sets of
>   | options. At least one option from each set must be selected.
>
> The OPTIONS, however, are handled in different way:
>
>   $ grep "PKG.*OPTION" mk.conf
>   PKG_DEFAULT_OPTIONS=    -arts -dvdread -esound
>   PKG_OPTIONS.kdebase=    debug -sasl
>   PKG_OPTIONS.apache=     suexec
>

This is coming along with the radio options.

>
> Their developments of pkg_* tools contain facilities to implement a 
> good
> package manager out-of-the-box, e.g. pkg_add there has flags:
>
>   | -A      Mark package as installed automatically, as dependency of
>   |         another package.  You can use
>   |                pkg_admin set automatic=YES
>   |         to mark packages this way after installation, and
>   |                pkg_admin unset automatic
>   |         to remove the mark.  If you pkg_add a package without
>   |         specifying  -A after it had already been automatically
>   |         installed, the mark is removed.
>   | -U      Replace an already installed version from a package.
>   |         Implies -u.
>   | -u      If the package that's being installed is already 
> installed,
>   |         an update is performed.
>
> These are crucial to effective binary package management.
>

All of this can be done a better way with pkgng


regars,
Bapt