svn commit: r534093 - in head: . audio audio/festvox-czech audio/gkrellmvolume2 audio/mixmos audio/mma audio/pd-cyclone audio/shorten audio/taglib-sharp audio/xhippo biology biology/consed biology/...

Ulrich Spörlein uqs at freebsd.org
Fri May 8 13:32:54 UTC 2020


On Thu, 2020-05-07 at 09:44:43 +0200, Baptiste Daroussin wrote:
> On Thu, May 07, 2020 at 09:29:56AM +0200, Ulrich Spörlein wrote:
> > Am Mi., 6. Mai 2020 um 10:37 Uhr schrieb Antoine Brodin <antoine at freebsd.org>:
> > > Trying build of xvattr-1.3_10 even though it is marked BROKEN.
> > > ===>   xvattr-1.3_10 depends on file: /usr/local/sbin/pkg - found
> > > => xvattr_1.3.orig.tar.gz doesn't seem to exist in
> > > /poudriere/ports/custom1/distfiles/.
> > > => Attempting to fetch
> > > http://xvattr.sourcearchive.com/downloads/1.3/xvattr_1.3.orig.tar.gz
> > > fetch: http://xvattr.sourcearchive.com/downloads/1.3/xvattr_1.3.orig.tar.gz:
> > > Not Found
> > > => Couldn't fetch it - please try to retrieve this
> > > => port manually into /poudriere/ports/custom1/distfiles/ and try again.
> > > *** Error code 1
> > >
> > > Stop.
> > > make: stopped in /poudriere/ports/custom1/x11/xvattr
> > >
> > >
> > > Antoine
> > 
> > Thanks for having another look. Of course, I already have those
> > distfiles so the ports continue to build fine for me. I haven't
> > actually _run_ esniper in forever, so I wasn't aware of the runtime
> > breakage.
> > 
> > Overall, this mass deletion looks like we're optimizing developer
> > convenience over our users convenience :/
> 
> I do disagree here: user experience is bad when we cannot build the actual port.
> 
> When the ports is marked as broken, the regular users cannot already use them.
> We keep the ports as broken for 6 month before deletion, so anyone willing to
> fix them has more than time to do it. After those 6 month we are deleting them.
> Which means they have already been put out of the scope of the actual final
> users for at least 6 month (plus the time it has been unnoticed as broken before
> being marked as broken).
> 
> So for end users: being broken, being marked as broken and being removed from
> the ports results in the same situation: there is no binary package at all. The
> first being the worst because he may try to build and end up in a broken
> situation.

I'm certain we cannot agree on this point, but let me retort anyway:
this situation is not the worst, it's the _best_ possible situation!

It conveys to an interested (!) user that sysutils/hidesvn had a
working port to FreeBSD that was working at some time. It conveys the
place/category in the ports tree it was in, and it gives them an
opportunity to fix the port (it's just a size mismatch after all).

It makes no difference to the user running `pkg add`, yes. And I would
say that keeping the broken port around and run shlib bumps against it
isn't that much of a burden to the project.

Now we've deleted it, so:
  - 2 years from now, an interested user can't possibly know a port used
    to exist.
  - they build a ports Makefile from scratch, a steep learning curve
  - they stick it under devel/hidesvn, because clearly it's a developer
    tool.
  - how the eff are they supposed to know to look for deleted ports?
    it's not like the names are unique, it could've been called
    hide-svn. And let's not forget our strange need to prefix tools with
    the script interpreter they need to run, like py37-iocage, etc.

> For the developers, being marked as broken help noting the port is actually
> broken. (I know portsmon is dead and so there is no automatic notification in
> case something is marked as broken, but this can be fixed by using services
> provided by freshports and/or phabricator).
> 6 month broken, the dev has more then plenty of time to fix it.
> After those 6 month the developer can still resurect the port easily (we are
> using a VCS it is not as if it was destroyed forever).

The maintainer could, yes, but without portsmon, how are they to know?
_My_ poudriere instance was building all those ports just fine!
What if there's no maintainer or they have moved on? As I wrote, for
some prospective/potential new contributor to FreeBSD it would be much
easier to bang a BROKEN port into shape than magically divine that such
a port used to exist and resurrect them.

Cheers
Uli


More information about the svn-ports-head mailing list