Ravenports, what's missing for you?

Sat Aug 4 21:46:19 PDT 2018

John Marino <dragonflybsd at marino.st> wrote:

> On 7/20/2018 16:06, Predrag Punosevac wrote:
> >
> > Hi John,
> >
> > First off I would like to thank you on your work on DPorts, FreeBSD
> > ports tree, and synth in particular. It seems like it was yesterday when
> > Matt announced that DF will be switching from pkgsrc to Dports
> >
> > https://marc.info/?l=dragonfly-users&m=138135161602547&w=2
> >
> > but I am sure it feels like an eternity to you. You managed more or less
> > on your 100% on your own to keep Dports in sync with FreeBSD ports three
> > and make DF usable to common folks like myself.
> 
> I had some help, but yeah, I did the lion's share of the work.
> 
> 
> > This should come as a no surprise to anyone as you were the single point
> > of failure and even if you did not get sidetracked by synth and
> > ravenports sooner or later somebody (preferably community) would have to
> > step in.
> 
> It's been a problem as long as DF has existed.  Back in the pkgsrc days, 
> it always seemed it was one or two people fixing all the breakage. 
> We've always needed a real team to do packaging but have never truly had 
> one.
> 
> 
> >
> > I am not sure how to read lack of response to your candid e-mail you
> > sent almost 2 months ago.
> 
> Here's how to read it:
> Deadlines spur action.  As long as DPorts is working, there's nothing 
> spurring change.  There's no immediate need to do anything.  It's basic 
> human nature.
> 
> > Personally my main concern is that Ravenports
> > is an infrastructure. Even the best infrastructure without community is
> > worthless. So instead of answering your question I will ask you a
> > question. Do you feel that there is momentum behind Ravenports and build
> > up of the community?
> 
> The goal is to build up a community.  The flash doesn't even need to 
> come from DF.  Any sizable project with packaging needs could 
> contribute.  I'd be hard-pressed to say there is currently "momentum" 
> but the word is getting out and things can change quickly.
> 
> > Minix and SmartOS use pkgsrc while OmniOS
> > practically has no package system and uses SmartOS pkgsrc repos.
> 
> I actually think Solaris/Illumos users could be some of the first real 
> adopters, including OmniOS.  The solaris repository is still missing 
> 300+ packages.  Since I'm basing on Solaris 10, a bunch of functions are 
> missing from libc that recent software assumes is available everywhere, 
> which complicates package building.  Once its on par with the rest of 
> RP, the solaris offerings will be quite attractive.

That was exactly the reason I mentioned Illumos's distros (OmniOS,
SmartOS) as well as Minix. However their communities appear to be so
tiny to the point of making them irrelevant. 

> 
> > I see
> > some discussions in Gentoo's and Funtoo's communities. What I am trying
> > to say is that you can fix here and there few ports to Ravenports
> > infrastructure but you can't you fix 25000+ ports from FreeBSD ports
> > tree.
> 
> That number is misleading.

+1 

Could not agree more with you. As a primarily OpenBSD user I am
accustomed to a small but well maintained ports tree from which obsolete,
unmaintained, and security problems ridden ports are aggressively removed
I can't stand that oversized FreeBSD ports three. Packing system with
automatic dependency resolution is NP hard problem to begin with.
FreeBSD folks are making it even harder by not removing crap.

> 1) inflation from flavors.  2) tons of old packages that never had many 
> users and aren't updated and 3) count is inflated due to lack of 
> subpackages and inferior flavors vs RP variants.
> 
> What I'm trying to say is that the "core" number of packages that most 
> users would need is much smaller.  For example, isn't OpenBSD packages 
> on the order of 6,000 - 7,000 ?
> 

+1 

The OpenBSD release featured 7990 packages for aarch64, 9912 for amd64,
8149 for mips64, and 8401 for sparc64 (powerpc had 8809 and it might
become more interesting in the future as the efforts to port OpenBSD
to Power9 hardware are under the way). I think that those number include
flavors so you are right on money in terms of number of ports which
people actually use with one caveat. Xenocara is the part of OpenBSD
proper. On DF XOrg is part of the ports tree. 

However you are missing more or less all the ports I personally consider
essential for running servers:

smartmontools
net-snmp
nfdump
nfsen
bro
rrdtool
apcupsd
nut
collectd
influxdb
grafana
ipmitool
monit
librenms
syslog-ng
lsof
clamav

as well as things as trivial as 

mupdf
unison
scrypt
lynx
duplicity
borgbackup
rsnapshot
ssvnc
rdesktop
acme-tiny

Note that above list is a reflection of my personal taste when it comes
to functional, and metric monitoring as well as centralized loggin but
it is not complete by any means. I did mentioned few generic tools which
I find useful for desktop as well as server users just to give you an
idea how much you are missing. You will also notice that some of the
ports I listed are broken on DPort tree as well (collectd, monit come
first to mind). The list doesn't include any of ZFS programs which would
be show stopper for OmniOS and SmartOS users. It also doesn't include
anything related to my firewall of choice PF or LDAP for that matter.

I don't expect that you spend next 10 months not sleeping and trying to
port all those things to Ravenports. Even if you were crazy enough to
try to do that I thing that effort involved exceeds the capacity of a
single human being. My intention is to illustrate one more time that
Ravenports infrastructure without strong following is not too useful to
regular users like myself.  

Best Regards,
Predrag

> > I see your job is to bootstrap ravenports to different
> > architectures aarch64, sparc64, and possibly different OSs. However your
> > job is not to maintain ravenports tree.
> 
> well, I've been doing it.  Ravenports is the most "fresh" ports 
> repository of all of them.  Ref: https://repology.org/
> 
> > In particular I am concern about
> > regression testing for such massive tree structure. As you know better
> > tools often lose to bad solutions (your synth is an example) if they
> > don't have the community and political support.
> 
> I'm not really getting what the concern is here.
> I test the tree in its entirety before publishing, something else no 
> other repository does.  That's proven to be more effective than other 
> systems I've worked on, especially pkgsrc.  (FreeBSD has exp-runs that 
> help in that area).
> 
> > Even decent tools like
> > pkgsrc get into the trouble if they over advertise and over sell (pkgsrc
> > is major pain on anything besides NetBSD as DF community is all to well
> > aware).
> 
> In my opinion, pkgsrc definitely oversells which is why I created my own 
> system.  Also in my opinion, Ravenports achieves what it promises, so 
> that's the difference.  It's a better approach to solving the same 
> problem.  Although to be fair, it's not really the same problem.  pkgsrc 
> really wants to work on tons of different, low resource systems where RP 
> is aimed at common, modern systems.  It's hardware support will depend 
> on that future community.
> 
> >
> > What is the plan of DF community for the time after Dports and John
> > Marino putting 80+ hours a week of free work?
> 
> Well, I'm not doing that much work, but each iteration of DPorts does 
> take an increasingly unacceptable amount of my time.  At some point I'm 
> probably going to just stop doing dports and let that decision spur 
> action.  Not sure when but probably not that far off.
> 
> John