cvs commit: ports/cad/admesh Makefile

[Dmitry Marakasov]

* Matthias Andree (mandree at FreeBSD.org) wrote:

> > Maybe we should stop doing things that raise such discussions then?
> 
> No.  Such poking the sleeping is necessary to get action taken at all.

There should be a reason for taking action. There is none.

> > "Dead" means it doesn't build or doesn't work. Which exactly of
> > these "unfetchable" ports doesn't build or doesn't work?
> 
> It's irrelevant.  Unmaintained ports of any kind are a danger to the end
> users.  They might miss crucial (security or critical) patches, and you
> can't judge the quality of software by "it builds and we mirrored an
> obsolete version years ago".

You can't judge the quality of software by "it is maintained" or
"it is the latest version" either, actually there is no corellation
at all. For the security, we have portaudit.

> Typically this situation arises if there are no users of a port left,
> else the complaints come much earlier.

Complaints come when there is a problem. But in this case there is
no. You may create it for no reason though, which is a way to go.

> And if there are no users, culling a port no matter whether your
> local culture considers it "dead" is not a loss except that we
> might some day fall below 20,000 ports.
> Which is neither likely nor undesireable. :)

> > That is strange definition of "dead". Does it stop being dead if I
> > mirror distfiles? Have all dependent ports (on graphics/lib3ds,
> > lang/expect, for example) suddenly became dead too?
> 
> You offer an "upstream" package and become the contact for issues. Just
> mirroring bit-rotten crap isn't going to help anyone.  Unsupported
> software is plainly and clearly a dead end, and I try to avoid running
> in such dead ends whenever I can.

You just can't decide for all users.

> Possibly we should always mark ports for removal for three months after
> the point in time when the maintainer gets reset to ports at .

Nice. Well that'll only result in two processes: more and more ports
will have maintainers reset and then removed, and remaining maintainers
will take more and more ports beyond their ability to maintain them,
both will lead to collapse. Is this also not undesirable?

> > What has happened is users being unable to build perfectly working
> > ports because of unneeded BROKEN's. FreeBSD ports are criticized for
> > frequent build problems, there are talks about stable port branch
> > for user to experience less frustration with ports tree, yet such
> > plain sabotage is happening.
> 
> False. Users can set TRYBROKEN=yes and see how far they get.

To know of TRYBROKEN, user should read either porter's handbook or
bsd.port.mk source, as it is not mentioned in handbook or any
manpage, while the user should't be required to read extra docs to
install a working port at all.

> False in that I don't see "FreeBSD ports that are criticized for
> frequent build problems".

Well, you should communicate with users more - then it becomes
apparent. I dwell on a russian FreeBSD site bsdportal.ru and see
ports problems quite often. And now I wonder what should I say
if a user asks why $port he wants doesn't build becase $dependent_port
is marked 'does not fetch' even after he downloaded the distfile
on his own? "FreeBSD guys don't want you to use this ports, sorry, go
away or fix it". That is what I call a nice attitude.
Also there had been a huge article an a discussion thread on "Key
FreeBSD problems and a way to solve them" after Rambler and Yandex
(largest FreeBSD using companies in Russia) decided to switch from
FreeBSD to Linux, which also mentions port problems and, which is
much worse, an attitude like yours. Let me translate an excerpt:

" Social problem of FreeBSD comminity is disregard to needs of plain
users, which do not belong to the community core. Developers tend
to write the system "for themselves" e.g. for those who will use
it despite the inconveniences, and others needs are plainly ignored
with "we don't need this" argument. Meanwhile, even a power user
is not a zealot, and many of those who could use and contribute to
FreeBSD, do switch to other systems because of minor technical
problems which were solved there (but not in FreeBSD) and the
unwilingness of FreeBSD community to change anything. "

And yet we complain on lack of manpower.

> But if you want stable ports, you can deinstall all FreeBSD ports and
> install those from pkgsrc. It works, is supported on FreeBSD and

Yes, yes - deinstall ports, deinstall FreeBSD. That is not solving
problems of ports.


A bit of constructive. While writing this I've got an idea: why
don't we introduce DEAD variable for this case?

By default, it works as BROKEN, however it displays more verbose
message like:

===>  foo-1.0 is marked as dead.
This means that the port's upstream has disappeared, it is not
fetchable, is not kept up-to-date and may be broken or vulnerable.
You may still build this port on your own rish by adding TRYDEAD=yes
to make arguments or enironement. Note that dead port will be
eventually removed from the ports tree if nobody steps forward to
become its maintainer and/or fix it.

This gives user a hint on what is the problem, how to build a port
and what to do to fix a problem, and motivates him to become a
maintainer.
This satisfies me, as the user now has a chance to do what he needs,
and I guess it should satisfy you as it does "poke the sleeping".
Moreover, we can use it somewhat wider than BROKEN to mark some
more dead (but still fetchable) ports (within reasonable, of course,
as overuse will lead to TRYDEAD ending up in user's make.conf).

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru