Re: [89493] trunk/dports/python/py-werkzeug/Portfile

> append to, don't overwrite, portgroup dependencies

Is this something that's worth making warning in lint?

Re: [89493] trunk/dports/python/py-werkzeug/Portfile

On Jan 31, 2012, at 18:43, Jeremy Lavergne wrote:

>> append to, don't overwrite, portgroup dependencies
> 
> Is this something that's worth making warning in lint?

It's probably a good rule of thumb that if you include any portgroup, you should -append to, not overwrite,
any dependencies, just in case that portgroup now or in the future declares dependencies. There are many
cases where it won't matter, but it's probably a good idea to get in the habit of -appending just so that you
don't forget to do so when it really does matter.

adduser in destroot

I see that quite a few ports call adduser and addgroup in the destroot
phase. Isn't this going to fail if we're installing from a binary (and
skip destroot)?

Dan

--

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/

Re: adduser in destroot

On 2012-2-1 14:28 , Dan Ports wrote:
> I see that quite a few ports call adduser and addgroup in the destroot
> phase. Isn't this going to fail if we're installing from a binary (and
> skip destroot)?

Yes. Ports that do this should be changed to use the add_users option
instead.

- Josh

Re: [89515] trunk/dports/python

Re: adduser in destroot

On Feb 1, 2012, at 12:17 AM, Joshua Root wrote:

> On 2012-2-1 14:28 , Dan Ports wrote:
>> I see that quite a few ports call adduser and addgroup in the destroot
>> phase. Isn't this going to fail if we're installing from a binary (and
>> skip destroot)?
> 
> Yes. Ports that do this should be changed to use the add_users option
> instead.

Looks like there are currently 76 ports using adduser and/or addgroup.

Should some form of initiative be created?

nomaintainer
    angband
    gnome-libs
    tomcat5
    assp
    exim
    mailman
    nefu
    openntpd
    py-pgasync
    slocate
    privoxy
    zope
openmaintainer
    mysql4
    percona-server
    dbus
    jnethack
    gdm
    hadoop
    tomcat6
    amavisd-new
    cyrus-imapd
    dovecot
    avahi
    murmur
    nagios
    quagga
    rabbitmq-server
    squid3-devel
    zabbix
    policykit
    boxbackup
    clamav-server
    puppet
    canna
alpha
	munin
arhbkb@...
	nsd
aschenke
	larn
	moria
	rogue
bfulgham
	geneweb
cbellot@...
	postgrey
compconsultant@...
	fcron
	qmail-spamcontrol
	vpopmail
dluke@...
	milter-greylist
fclaire@...
	xymon
	xymon-server
jameskyle
	backuppc
jogwtr@...
	mariadb-server
jwa
	couchdb
	couchdb-devel
krischik
	leafnode
landonf
	openldap
markd
	moomps
	nrpe
	nsca
	sendpage
matt@...
	maildrop
miwi@...
	nut
mnick
	miredo
mww, jwa
    postgresql7
    postgresql80-server
    postgresql81-server
    postgresql82-server
    postgresql83-server
    postgresql84-server
    postgresql90-server
    postgresql91-server
pixilla
	dovecot2
	rbldnsd
	sqlgrey
rambiusparkisanius@...
	perforce
ryandesign
	mysql5-server
ryandesign, jwa
	mysql5-server-devel
sfiera
	lastfmsubmitd
simon@...
	pulse

Re: [89525] trunk/dports/python/py-aplpy/Portfile

Re: [89525] trunk/dports/python/py-aplpy/Portfile

Re: [89525] trunk/dports/python/py-aplpy/Portfile

Ok, thanks for clarifying! I won't update the revision in future when
simply converting a port to unified format.

Cheers,
Tom

On 1 February 2012 19:47, Frank Schima <macsforever2000@...> wrote:
> You don't need to update the revision when unifying python ports.
>
>
> On Feb 1, 2012, at 10:05 AM, robitaille@... wrote:
>
> Revision 89525 Author robitaille@... Date 2012-02-01
09:05:15 -0800
> (Wed, 01 Feb 2012)
>
> Log Message
>
> py-aplpy: set revision to 1 (should have done it when updating to unified
> port format)
>
> Modified Paths
>
> trunk/dports/python/py-aplpy/Portfile
>
> Diff
>
> Modified: trunk/dports/python/py-aplpy/Portfile (89524 => 89525)
>
> --- trunk/dports/python/py-aplpy/Portfile	2012-02-01 17:04:01 UTC (rev
> 89524)
> +++ trunk/dports/python/py-aplpy/Portfile	2012-02-01 17:05:15 UTC (rev
> 89525)
> @@ -6,6 +6,7 @@
>
>  name                py-aplpy
>  version             0.9.6
> +revision            1
>  maintainers         robitaille stsci.edu:mperrin
>
>  categories-append   science
>
> _______________________________________________
> macports-changes mailing list
> macports-changes@...
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
>
>

Suggestion for new pseudo-portnames

The recent RFC for making an alias action for active and inactive
reminded me of some queries that I frequently use when working with
ports.

Specifically, outdated ports that have been upgraded (redundant), and
uninstalled dependencies (outstanding).

redundant can currently be achieved with "actinact and inactive"

For example:
> port selfupdate
> port echo outdated
> port upgrade outdated

> port uninstall actinact and inactive
or rather
> port uninstall redundant

outstanding right now would be "rdepof:<port> and not installed"

For example:
> port echo outstanding:gimp
...very long list
^C
> forget this!

One quandary for "outstanding" is whether the rdep search should be
performed first, or should branches be pruned as soon as an installed
port is discovered? Maybe separate that question into "outstanding"
and "routstanding"?

There may be better names of course.

Is this worth submitting an issue to trac? Or, are these just
redundant names for queries that are already possible?

I'd like to start hacking on base myself, so I'll be looking at
port.tcl, but I don't anticipate having anything to submit anytime
soon, just in case anyone considers this such an amazing idea they
can't wait to implement it .

--

-- 
arno  s  hautala    /-|   arno <at> alum.wpi.edu

pgp b2c9d448
_______________________________________________
macports-dev mailing list
macports-dev <at> lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev