portmaster, portupgrade, etc
bsd-lists at bsdforge.com
Thu Oct 5 22:23:27 UTC 2017
On Thu, 5 Oct 2017 22:05:05 +0000 Grzegorz Junka <list1 at gjunka.com> wrote
> On 05/10/2017 21:53, Chris H wrote:
> > On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger <adamw at adamw.org> wrote
> >>> On 5 Oct, 2017, at 10:28, Steve Kargl <sgk at troutmask.apl.washington.edu>
> >>> wrote:
> >>> On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:
> >>>>> On 5 Oct, 2017, at 9:25, Steve Kargl <sgk at troutmask.apl.washington.edu>
> >>>>> wrote: Which brings me back to my i686 laptop with limited resources.
> >>>>> If portmgr makes it impractical/impossible to easily install ports
> >>>>> without a sledge hammer, then testing possible future patches to
> >>>>> libm will simply skip i686 class hardware.
> >>>> I'm not clear what role you think portmgr has in this. Portmgr
> >>>> merely brings new features to the ports tree. Portmgr itself is
> >>>> responsible for no build tool other than "make install".
> >>>> I don't know how many times I need to keep saying this, but
> >>>> portmgr is not killing off portmaster. There is simply nobody
> >>>> developing portmaster anymore, and that is not portmgr's
> >>>> responsibility. There ARE people developing poudriere, and
> >>>> that is why poudriere continues to work with new ports tree features.
> >>> I suppose it's a matter of semantics. If the Makefiles and *.mk
> >>> files under /usr/ports are altered to allow subpackages and
> >>> flavours to enhance pkg and poudriere, which will break portmaster
> >>> further, then yes portmgr has made a decision to endorse a sledge
> >>> hammer over simple tools.
> >>> Mere users of the ports collection are not privy to discussions
> >>> on a portmgr alias/mailinglist. A quick scan of the members of
> >>> portmgr and contributors to poudriere show at least 4 common
> >>> members. There are 8 people listed under portmgr. When decisions
> >>> were being made on the introduction of subpackages/flavours into
> >>> the ports collection, did the 4 common members recluse themselves
> >>> from any formal or informal vote? If no, then there is certainly
> >>> a conflict-of-interest in what is best for the ports collection
> >>> versus what is best for poudriere.
> >>> Yes, portmaster is currently unmaintained. Doug Barton left
> >>> FreeBSD developement because he was continually brow beaten
> >>> whenever he pointed out what he felt were (serious) flaws in
> >>> FreeBSD and in the ports collection.
> >> Not quite. It works in the other direction. Ports isn't designed for
> >> poudriere. Poudriere is designed for ports. 100% of the flavours
> >> development is happening in public. Anybody who wishes to work on
> >> portmaster can participate in the process too.
> >> I think you have a misperception of the relationship between portmgr and
> >> poudriere. The coming flavours would break poudriere too, except there are
> >> people actively developing it.
> >> You seem to be fully convinced in a conspiracy to destroy portmaster, and
> >> I don't get the impression that I'm going to change your mind. All I can
> >> tell you is that impending portmaster breakage is NOT by design, and is
> >> only happening because portmaster isn't actively developed anymore. If
> >> you'd like to believe in secret poudriere cabals and anti-portmaster
> >> conspiracies, that's up to you.
> >> # Adam
> > While I have no intention to speak on Steve's behalf. I /would/ like
> > to speak in his humble defense;
> > over year ago, I attempted to become maintainer for
> > ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
> > it's value, and 2) it had been scorned for some time, and there were
> > /many/ discussions to have it removed. At the time I attempted the
> > request, it had not "officially" had a maintainer, and there was
> > serious talk as to /really/ having it removed from the ports tree.
> > bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
> > mailing list for portmaster /will/ show /many/ heated discussions
> > regarding it's removal -- this thread included. In any event, after
> > a few inquiries regarding taking maintainer for the port. My request
> > was ultimately declined. I was deemed unqualified. That judgement was
> > unfounded. :(
> > Granted, maintenance of portmaster is no small feat -- it's an
> > enormous scriptbal. But now some months later, I am maintainer for
> > ~120 ports! perform a search for portmaster@ and see for yourself.
> > You can say what you will about some of those ports, but what it
> > /does/ show, is commitment, and long term commitment to boot!
> > I grow weary of the circular discussions surrounding portmaster. So
> > this is what I'd like to propose. It's maintenance is a bigger job for
> > anyone whom is not it's original author, for anyone that did not
> > grow it from scratch, and become so intimately familiar with it. So
> > perhaps a better solution might be for me to attempt again ask to
> > become maintainer. But this time, make it a group effort -- if for
> What does it mean in practical terms? A list of signatories under your
> candidature and a recommendation letter? Endorsements sent to a
> particular email?
> I don't quite understand why would anybody want to decline a request to
> maintain a port that is unmaintained otherwise? Are they expecting
> better candidatures? I would understand if they had 10 proposals to
> maintain the same port, but not if there is just one? But I am not good
> at politics so maybe I am missing something.
I'm afraid I'm not really following you. What I'm saying, is that I
am seeking to be Maintainer for ports-mgmt/portmaster.
I am saying that it is an especially difficult task to perform --
especially in light of 1) it isn't even up-to-date for the /current/
state of the ports tree, and 2) isn't [yet] ready for Flavo[u]rs, 3)
let alone sub-packages. So I would feel more inclined to make the
Maintenance effort, a /team/ effort. So that those whom currently
depend on it, and continue to enjoy it's use.
I hope this helps clear my intentions up. :)
P.S. If it's regarding the "heated discussions" regarding it's removal;
simply grep the ports mailing list. In fact, here's an excerpt from
the SVN commit logs:
ports-mgmt/portmaster: DEPRECATE without expiration date
The portmaster script hasn't had an official maintainer in 9 months and 2
years before that it was only patched in reaction to changes in the ports
framework. There are many unclaimed PRs in the bugzilla database, many
known bugs, and several areas where portmaster no longer aligns with how
ports work today. The problem isn't simply getting a maintainer; that
person has to be a ports framework expert and it appears that the people
with these qualifications don't want anything to do with this port.
Moreover, there are better options available. All FreeBSD platforms
support ports-mgmt/poudriere (although some many struggle under the load)
and the most common amd64 and i386 platform users have the additional
option of ports-mgmt/synth which is user-friendly, lightweight, and aimed
at users of portmaster, portupgrade, and even poudriere.
Unless something drastic regarding portmaster occurs, it's nearing its
natural EOL, so it's users should evaluate alternatives and try to
migrate off of it.
Under strong objection and mandate by portmgr, remove DEPRECATION
I've been ordered by portmgr to remove DEPRECATION designation because
others have indicated they believe people should not be so directly
informed of its poor state. Despite the fact that there was no expiration
date set and that functionality was not affected in any way (leaving now
informed people free to use this unmaintained port), it was considered a
Let the record show that I strongly object to this decision and that I
firmly believe that portmaster is a port that *must* have a competent
maintainer that can *develop* it. It should *not* be allowed to be
unmaintained and still maintain a presence in FreeBSD documentation.
> freebsd-ports at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
More information about the freebsd-ports