Packaging base system (again) [Was: svn commit: r343118 - in head/usr.sbin: . trim]

Maxim Sobolev sobomax at freebsd.org
Thu Jan 17 23:18:52 UTC 2019


On Thu, Jan 17, 2019 at 2:42 PM Enji Cooper <yaneurabeya at gmail.com> wrote:

> > Perhaps even by forking the whole ports idea into a smaller
> closely-guarged subset. Something like a new baseports repository, which
> might have structure like baseports/usr.bin/xxx, baseports/usr.sbin/yyy
> etc. Then add some automagic glue to kick in on every commit and transfer
> this into valid ports, which is going to be packaged by the poudriere and
> such. This way we could reduce amount of port-foo average src committer
> needs in order to maintain code. I am almost tempted to sit and write
> something over the next weekend or few of thereofs. Using usr.sbin/trim as
> an example.
>
> Please see my above comment.
>

Well, I don't think your comment really addresses my concerns here. Correct
me if I am wrong, but you seem suggesting that every src developer would
also need some external account (github in this example) to maintain his or
her chunk of code independently of everyone else's. This is pretty much a
no-go from starters.

There are also many more major issues with such approach, such as
completely different branching model for src and ports as an example. ports
is a good framework in general, for maintaining software produced by
external entities. I don't feel it's very appropriate for maintaining
software produced by the Project itself, though, due to complexity
inherited with that. We need something simpler and more self-consistent, at
the same time I see no reasons why it could not utilize some if not all
tooling with we build around ports/Mk over the years. IMHO.

-Max


More information about the svn-src-all mailing list