From owner-freebsd-ports@FreeBSD.ORG Thu Nov 14 10:16:00 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3F555DF for ; Thu, 14 Nov 2013 10:15:59 +0000 (UTC) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77BA52D45 for ; Thu, 14 Nov 2013 10:15:59 +0000 (UTC) Received: from [80.67.16.118] (helo=webmailfront01.ispgateway.de) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VgthW-0007SU-Fw for freebsd-ports@freebsd.org; Thu, 14 Nov 2013 10:59:02 +0100 Received: from his1.his.de (his1.his.de [192.124.237.237]) by webmail.df.eu (Horde Framework) with HTTP; Thu, 14 Nov 2013 10:59:02 +0100 Date: Thu, 14 Nov 2013 10:59:02 +0100 Message-ID: <20131114105902.Horde.rVct7VhQLf30W6LmX6xT6Q1@webmail.df.eu> From: Marcus von Appen To: freebsd-ports@freebsd.org Subject: Re: Proposal for Authors / Vendors in ports References: <5283E4A0.6090107@pcbsd.org> <20131114073008.GG90670@droso.dk> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: ZnJlZWJzZEBzeXNmYXVsdC5vcmc= X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: mva@freebsd.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 10:16:00 -0000 Jason Helfman : > On Wed, Nov 13, 2013 at 11:30 PM, Erwin Lansing wrote: > >> On Wed, Nov 13, 2013 at 04:47:20PM -0500, Eitan Adler wrote: >> > On Wed, Nov 13, 2013 at 3:27 PM, Melvyn Sopacua >> wrote: >> > > On Wed, 13 Nov 2013, Kris Moore wrote: >> > > >> > >> >> > >> Wanted to run this by the ports community, see your thoughts. We build >> > >> our PBIs from the ports system, and are able to parse most of the >> > >> information out for display graphically, like descriptions, >> maintainers, >> > >> website, License, etc. However we currently don't have a way to pull >> the >> > >> actual name of the upstream vendor / author. I.E. for Firefox the >> vendor >> > >> would be "Mozilla". >> > > >> > > >> > > WWW: [Mozilla](http://www.mozilla.org/) >> > > >> > > So, markdown format in pkg-descr. Seems the least amount of work? >> > >> > This adds a lot of work to the parser. >> > >> > IMHO we should have VENDOR_WWW and possibly VENDOR_NAME in the port's >> > Makefile. It should not be hard to automate this for VENDOR_WWW since >> > we already have the WWW: lines in pkg-descr. >> > >> >> That sounds like an excellent idea. I'm just a bit worried about >> spreading the information over too many places, and would rather split >> content from logic and add these to pkg-descr as well next to the >> current WWW. I know we're not consistent already with things like >> COMMENT and LICENSE already in the Makefile, so won't ojbect too much to >> where these end up. >> >> Erwin >> > > With good ideas usually bloat is not too far behind. I think this is a > great idea, however I think it would be > worth considering a potential new file for this, that can be parsed without > causing too much new data in existing > files. Perhaps, a file named pkg-vendor. In this file, all sorts of > information can be places, and parsed or used > by our package infrastructure. I like that idea, but how about carrying it on a bit to enable more metadata, such as Trove categorization, generic descriptions, links to relevant sites of interest for the port, etc.pp. Instead of pkg-vendor, I'd name it pkg-meta or so and something like the following comes into mind: VENDOR: ' NAME : Vendor WWW : UrlOfVendor ' UPSTREAM: ' CONTACT : UpstreamDeveloperContact BUGS : LinkToUpstreamBugTrackerOrWhatever CHANGELOG: LinkToUpstreamChangeLog ' CLASSIFICATION: ' trove classifiers here ' LINKS: ' DOC : LinkToOnlineReference DOC : OtherLinkToOnlineReference RELATED : LinkToRelatedProjectOfRelevance COMMERCIAL : LinkToCommercialSite/Support/whatever YOURIDEAHERE : .. ' Personally, I would not want to see that being parsed by some make-compatible implementation, but would rather see some supplementary script in Tools/ or something else to deal with this. Especially to avoid keeping the format limited to cope with the limitation of make and sh. Since the meta information are not necessary by the ports infrastructure (as pointed out earlier), supplementary third-party tools and projects can and should deal with it. Cheers Marcus