On Sat, Nov 04, 2017 at 12:06:09PM +0100, Martijn van Duren wrote:
> So what would be the desired requirements for this merge?
> - The module doesn't have any lib-depends to prevent pulling in all
> kinds of random packages.
> - The module must be a requirement for another port.
> - The module must not have any security implications.
>
> If these are the requirements than the following packages would be
> merged back into -main (or more precisely the different -SAPI packages):
> - bcmath
> - calendar
> - ctype
> - dom (libxml is a required extension, so no new dependencies)
> - exif
> - fileinfo? (no external dependency)
> - ftp
> - json
> - mysqlnd
> - mysql (depends on mysqlnd driver)
> - mysqli (depends on mysqlnd driver)
> - pdo
> - pdo_mysql (depends on mysqlnd and pdo driver)
> - phar? (Would leave sparc64 broken)
> - simplexml (see dom)
> - soap (see dom)
> - sockets
> - sysvsem? (I currently don't know if this has security implications)
> - sysvshm? (I currently don't know if this has security implications)
> - tokenizer
> - wddx (see dom)
> - xmlreader (see dom)
> - xmlrpc (see dom)
> - xmlwrite (see dom)
> - zip
>
> But would still leave the following as an invariables:
> - bz2 (external library - archivers/bzip2)
> - curl (external libarary - net/curl)
> - fileinfo? (security of this feature has been subject of debate before)
> - gd (extrenal libraries - graphics/{jpeg,png}
> - gettext (external library - devel/gettext)
> - gpm (external library - devel/gmp)
> - iconv (external library - converters/libiconv)
> - imap (external library - mail/alpine,-c-client)
> - intl (external library - textproc/icu4c)
> - ldap (external library - databases/openldap)
> - mbstring (external library - textproc/oniguruma)
> - mcrypt (external libraries - security/libmcrypt, devel/libtool,ltdl)
> - pcntl (security - process control)
> - pdo_pgsql (external library - databases/postgresql)
> - pgsql (external library - database/postgresql)
> - phar? (Should allow to build on sparc64 if we ignore the module there)
> - posix (security - does signals)
> - pspell (external library - textproc/aspell/core)
> - readline (libreadline, although that can be provided through base)
> - snmp (external library - net/netsnmp)
> - sqlite3 (external library - databases/sqlite3)
> - sysvsem? (I currently don't know if this has security implications)
> - sysvshm? (I currently don't know if this has security implications)
> - xsl (external library - textproc/libxslt)
>
> This list is about 50/50 and might seem completely unintuitive to the
> end-user. What would people think about pdo_mysql being included over
> pdo_pgsql or pdo_sqlite3 without knowledge of this discussion? -
> They could assume mysql/mariadb is the preferred database for the
> OpenBSD project, or think that the OpenBSD devs forgot to include the
> pdo_mysql package and start asking questions on the mailing lists.
> Or why do I have all my xml-tools and its kitchensink, but not xsl?
> Same for sysvsem/sysvshm vs sysvmsg?
> What about bzip2, curl? pretty widely used while the sysv* modules
> are a rarity (I was surprised even a single port uses them).
Welcome to the world of actual distributions. We are supposed to
be the expert and to know better than the end user.
There's nothing that prevents you from adding this kind of rationale
to the actual package DESCR.
One strong point of OpenBSD is that we actuall make this kind of
decision. Choosing best paths for software components, so that the
end-user doesn't have to worry too much.
I've never been a fan of debian where they split stuff into so
many very small packages that you never know what to install.
Now, think like an end-user. Assume they want to use php. What do
they do ? They add the main package. They try to run something.
They discover one dependency is missing. They add that dependency.
They do it another time...
How many times are they going to do it ?
The safe bet is that they usually give up after the 4th dependency,
and just add *everything* that has php in it.
Congrats, you just gave them enough rope so that they add fileinfo
by default.
