Date: Thu, 17 Jan 2019 18:37:25 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: rgrimes@freebsd.org Cc: Maxim Sobolev <sobomax@freebsd.org>, Cy Schubert <Cy.Schubert@cschubert.com>, "Conrad E. Meyer" <cem@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r343118 - in head/usr.sbin: . trim Message-ID: <201901180237.x0I2bP5m053193@slippy.cwsent.com> In-Reply-To: Message from "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> of "Thu, 17 Jan 2019 16:08:29 -0800." <201901180008.x0I08THg052763@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <201901180008.x0I08THg052763@pdx.rh.CN85.dnsmgr.net>, "Rodney W. Gri mes" writes: > > What I think we really need is some way to easily porti-ze useful stuff > > that would otherwise go into /usr/[s]bin, so adding things would be just as > > easy as hooking up SUBDIR into usr.[s]bin/Makefile. Yes, I know, this is > > topic almost as old as the FreeBSD Project itself, but perhaps we just did > > not approach it the right way. It was always the idea that we would just > > move bunch of stuff from src/usr.[s]bin repo into ports/. Which brings > > several important question such as "who is to host the distfile"? "where > > sources hosted", "who is to update the port when changes happen?" etc. > > > > 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. > > Couldnt the "distribution" just live as files commited into > the ports tree as a "work" hierarcy and the top level file > be marked as no fetch. We use to stick small stuff in ports > by putting there files in files/ and having that work IIRC. If it must live in one of our repositories, then a users, projects or other hierarchy in ports might be acceptable. However there would be too great a temptation to fork a random piece of software on the internet. baseports/usr.bin/whatever doesn't make much sense. If it's in ports it should use the ports infrastructure and install in $LOCALBASE. If it's in ports, it's not in base and should not be installed outside of $LOCALBASE. If it's to be installed in for instance, /usr/bin, then it must live in usr.bin. > > I really really dislike the idea of putting stuff from base in > external repositories and then fetching them, something just > feels fundementally wrong about that. Trim should not be in base/. If it's in ports it should be installed in $LOCALBASE not outside it. The point is, trim should not be in base. It should not live in /usr/src nor should it be installed outside of $LOCALBASE. If anything, as is it could be a port. It should not live in a user or project branch of base nor should it be sourced out of some hypothetical quasi FreeBSD source repository in ports or any other FreeBSD repo for that matter. It doesn't belong here at all. It's function can however be provided by dd. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201901180237.x0I2bP5m053193>