Re: What to do with old versions of Python, Perl, PHP, Apache1 (and others)?

[Mark Anderson]

I vote for killing a lot of them. Apache 1 for instance is a very bad thing
to be running right now. If they are EOL upstream, keeping them around is
also a bit of false hope to people that might need them. I know I for one
could not fix some of these builds since I don't have old enough OSes, and
I don't really care to.

—Mark
___
Mark E. Anderson 

On Thu, Feb 4, 2016 at 5:47 PM, Jeremy Lavergne 
wrote:

> On 02/04/2016 03:32 PM, Joshua Root wrote:
> >> The question is: what should be the general policy with these ports?
> >> How long should we keep them around?
> >
> > As long as they still build on some OS X version that base works on. If
> > they break and nobody steps up to fix them, that's a pretty good
> > indication that it's time for them to go.
> >
> > As you mentioned, there are all kinds of reasons why people have to test
> > against old versions. A deprecation warning in the description and notes
> > would be a good idea.
>
>
> Could this be considered reinforcing the expectation of no one fixing
> tickets?
>
> If people need to use the very old versions, we should encourage them to
> use source control to look up these Portfiles. While stubbing ports with
> this message would be helpful, I worry how many ports would become stubs.
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: What to do with old versions of Python, Perl, PHP, Apache1 (and others)?

[Jeremy Lavergne]

On 02/04/2016 03:32 PM, Joshua Root wrote:
>> The question is: what should be the general policy with these ports?
>> How long should we keep them around?
> 
> As long as they still build on some OS X version that base works on. If
> they break and nobody steps up to fix them, that's a pretty good
> indication that it's time for them to go.
> 
> As you mentioned, there are all kinds of reasons why people have to test
> against old versions. A deprecation warning in the description and notes
> would be a good idea.


Could this be considered reinforcing the expectation of no one fixing
tickets?

If people need to use the very old versions, we should encourage them to
use source control to look up these Portfiles. While stubbing ports with
this message would be helpful, I worry how many ports would become stubs.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: What to do with old versions of Python, Perl, PHP, Apache1 (and others)?

[Joshua Root]

On 2016-2-5 03:52 , Mojca Miklavec wrote:
> (for Python it's not entirely clear which ones are EOL)

Search for "Release Schedule" in the list of PEPs:


2.6 is no longer getting any updates at all. 2.7 is being maintained
with bug fixes until 2020 and possibly security fixes for some time
after that. 3.2 is just reaching the end of its security update period.
Later versions are still getting updates.

> The question is: what should be the general policy with these ports?
> How long should we keep them around?

As long as they still build on some OS X version that base works on. If
they break and nobody steps up to fix them, that's a pretty good
indication that it's time for them to go.

As you mentioned, there are all kinds of reasons why people have to test
against old versions. A deprecation warning in the description and notes
would be a good idea.

- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

What to do with old versions of Python, Perl, PHP, Apache1 (and others)?

[Mojca Miklavec]

Hi,

We have removed modules for old versions of Python and Perl, but there
are still many of these ports present:

- python24
- python25 (May 2011)
- python26 (Oct 2013)
- python27 (latest)
- (no python30)
- python31
- python32
- python33
- python34
- python35 (latest)
(for Python it's not entirely clear which ones are EOL)

- perl5.16 (eol 2014/05)
- perl5.18 (eol 2015/05)
- perl5.20 (supported)
- perl5.22 (latest)

- php52 (eol 2011/01)
- php53 (eol 2014/08)
- php54 (eol 2015/09)
- ... and newer ...
(see https://secure.php.net/eol.php)

- postgresql7  (eol 2010/10)
- postgresql80 (eol 2010/10)
- postgresql81 (eol 2010/11)
- postgresql82 (eol 2011/12)
- postgresql83 (eol 2013/02)
- postgresql84 (eol 2014/07)
- postgresql90 (eol 2015/09)
- postgresql91 (supported)
- postgresql92
- postgresql93
- postgresql94
- postgresql95
(see http://www.postgresql.org/support/versioning/)

- apache1 (eol 2010/02)

- gcc43
- gcc44
- ...

Some developers are calling for removal of these ports:
http://trac.macports.org/ticket/50512
while some users occasionally complain if old versions get removed:
https://trac.macports.org/ticket/50062

Daniel (dluke) said that anyone interested in keeping the ports should
have stepped up as a maintainer (but at least in case of Perl this is
not really an issue: I'm perfectly fine volunteering to maintain [read
as: do nothing to] these old ports).


The question is: what should be the general policy with these ports?
How long should we keep them around? Should we keep them or remove
them? And if we decide to remove them: should we have the same policy
for all rather than keep some forever while removing others as soon as
replacements are there?

I just wanted to clear this question up before acting on the ticket
linked above. I don't have a problem removing the ports, but in a way
I feel at least a bit sorry as long as those ports still work on all
OS X versions, don't need any maintenance and might still be somewhat
useful for people testing functionality of old versions.

Mojca


PS: Personally I would vote for some introduction of some kind of a
"purgatory" (if graveyard is reserved) section of MacPorts where all
of the outdated, broken, no longer maintained (not just without
maintainer, but abandoned from upstream and with hardly any real
users) ports would go once people agree that there is no real use for
them other than in some obscure cases. Then users who would still need
them would find it easy enough to install them.

I would then also find it easier to just move a port there rather than
keep asking around whether anyone was still using that particular
semi-broken port.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: launchd plist -- userid, home directory

[Craig Treleaven]

> On Feb 4, 2016, at 9:41 AM, Rainer Müller  wrote:
> 
> On 2016-02-04 15:15, Craig Treleaven wrote:
>> I was looking at modifying the buildbot / buildbot-slave ports to include a 
>> sample launchd plist.  I would like to be able to default the UserName and 
>> WorkingDirectory keys for the userid that is installing the port.
>> 
>> UserName
>> @someusername@
>> WorkingDirectory
>> /Users/@someusername@/buildarea
>> 
>> For example, if I’m installing the port and my userid is ‘wct’, I’d like to 
>> s/@someusername@/wct’/g .  
>> 
>> Within the portfile, how can I determine the userid that invoked ‘port 
>> install …'?
> 
> I would advise against doing this. The installed sample files would
> change depending on the user that ran the port command. The contents of
> all files installed by a port should be reflected by the canonical
> identifier of name/version/revision/epoch/variants.
> 
> Also this would not help if the user installs the port with a binary
> archive from one of our buildbots, they would always get a pre-defined
> username.
> 
> Wouldn't it make more sense to create a dedicated user to run the
> buildbot daemon? See add_users in portfile(7) and grep for examples in
> the ports tree. If you use some working directory in ${prefix}/var/ it
> could even be used out of the box without further configuration.
> 
> Rainer
> 
> [1] https://trac.macports.org/wiki/ReproducibleBuilds

Ah, yes, good points.  I wasn’t thinking of reproducible buids or the binary 
packages.  I was hoping to make it a little easier for a user to install a 
basic working buildslave*.   After the install, our user must run the 
‘buildslave create …’ command (with parameters we can’t determine ahead of 
time) to initialize the the files that the plist will be pointed to.  All that 
is beyond the scope of the portfile so I guess just providing a template of the 
plist is a reasonable approach.

Craig

*Our buildbot port is currently non-functional as we have a newer version of 
sqlalchemy-migrate than it can use.  Being looked at upstream:

http://trac.buildbot.net/ticket/3425#ticket

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: launchd plist -- userid, home directory

[Rainer Müller]

On 2016-02-04 15:15, Craig Treleaven wrote:
> I was looking at modifying the buildbot / buildbot-slave ports to include a 
> sample launchd plist.  I would like to be able to default the UserName and 
> WorkingDirectory keys for the userid that is installing the port.
> 
> UserName
> @someusername@
> WorkingDirectory
> /Users/@someusername@/buildarea
> 
> For example, if I’m installing the port and my userid is ‘wct’, I’d like to 
> s/@someusername@/wct’/g .  
> 
> Within the portfile, how can I determine the userid that invoked ‘port 
> install …'?

I would advise against doing this. The installed sample files would
change depending on the user that ran the port command. The contents of
all files installed by a port should be reflected by the canonical
identifier of name/version/revision/epoch/variants.

Also this would not help if the user installs the port with a binary
archive from one of our buildbots, they would always get a pre-defined
username.

Wouldn't it make more sense to create a dedicated user to run the
buildbot daemon? See add_users in portfile(7) and grep for examples in
the ports tree. If you use some working directory in ${prefix}/var/ it
could even be used out of the box without further configuration.

Rainer

[1] https://trac.macports.org/wiki/ReproducibleBuilds
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

launchd plist -- userid, home directory

[Craig Treleaven]

Hi:

I was looking at modifying the buildbot / buildbot-slave ports to include a 
sample launchd plist.  I would like to be able to default the UserName and 
WorkingDirectory keys for the userid that is installing the port.

UserName
@someusername@
WorkingDirectory
/Users/@someusername@/buildarea

For example, if I’m installing the port and my userid is ‘wct’, I’d like to 
s/@someusername@/wct’/g .  

Within the portfile, how can I determine the userid that invoked ‘port install 
…'?

Craig

(I realize that some folks may want a different userid to run this system.  
This is going to be a _sample_ plist; the user will always have to fill in the 
directory name for the master or slave.)

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev