A few words on cleaning up PERMIT_PACKAGE

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

A few words on cleaning up PERMIT_PACKAGE

Christian Weisgerber
A few words about cleaning up PERMIT_PACKAGE_*, since I've done
similar changes before.

You might think this will take care of itself over time, as ports
are updated and modified, they'll eventually all get cleaned up.
Past experience suggests that this won't happen or will take a very
long time.  A subset of ports is touched frequently, but there is
a long tail that sees no changes from one release to the next.  So,
yeah, eventually we'll need to sit down and do an explicit cleanup
run.

You want to do this in steps and eliminate the obsolete settings from
(1) modules and the ports that use them;
(2) all instances of Makefile.inc and the ports that use them;
(3) multi-package ports;
(4) the rest, which is simple now.

There are no modules that set PERMIT_PACKAGE_*, so that's it for
step (1).

If you want to move this forward, (2) is where we're at now.
There are 100+ Makefile.inc files that set PERMIT_PACKAGE_*.

Step (4) is very amenable to scripting.  There's really no point
in manually changing simple ports when they can be covered by a
script run, and it doesn't matter whether a thousand or five thousand
are left.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: A few words on cleaning up PERMIT_PACKAGE

Kurt Mosiejczuk-9
On Thu, Jul 11, 2019 at 11:12:14PM +0200, Christian Weisgerber wrote:
> A few words about cleaning up PERMIT_PACKAGE_*, since I've done
> similar changes before.

> You might think this will take care of itself over time, as ports
> are updated and modified, they'll eventually all get cleaned up.
> Past experience suggests that this won't happen or will take a very
> long time.  A subset of ports is touched frequently, but there is
> a long tail that sees no changes from one release to the next.  So,
> yeah, eventually we'll need to sit down and do an explicit cleanup
> run.

> You want to do this in steps and eliminate the obsolete settings from
> (1) modules and the ports that use them;
> (2) all instances of Makefile.inc and the ports that use them;
> (3) multi-package ports;
> (4) the rest, which is simple now.

> There are no modules that set PERMIT_PACKAGE_*, so that's it for
> step (1).

> If you want to move this forward, (2) is where we're at now.
> There are 100+ Makefile.inc files that set PERMIT_PACKAGE_*.

I'm seeing 129 instances of Makefile.inc that set PERMIT_PACKAGE_*

I'm seeing 3 multi-package instaces of PERMIT_PACKAGE_FTP-*
and 4 of PERMIT_PACKAGE_CDROM-*. And... those overlap. So
really just four multipackage Makefiles to fix. One of those is
tests/portcheck/t9/Makefile, so that one perhaps shouldn't be changed
before we finish.

I'm seeing 7066 Makefiles still setting PERMIT_PACKAGE_*.

> Step (4) is very amenable to scripting.  There's really no point in
> manually changing simple ports when they can be covered by a script
> run, and it doesn't matter whether a thousand or five thousand are
> left.

Is there a reason (3) is not amenable to scripting? As far as I know,
the multipackages will just mean there is a -subpkgname on the end of
what we are going to replace anyway.

There's also 74 instances of PERMIT_DISTFILES_FTP in files named
Makefile* in the ports tree currently. I have not checked the modules
yet.

Included below is a diff to switch the multipackage Makefiles I found that
use PERMIT_PACKAGE_*. I did not do tests/portcheck/t9/Makefile yet.

--Kurt

Index: archivers/p7zip/Makefile
===================================================================
RCS file: /cvs/ports/archivers/p7zip/Makefile,v
retrieving revision 1.46
diff -u -p -r1.46 Makefile
--- archivers/p7zip/Makefile 5 May 2019 22:34:40 -0000 1.46
+++ archivers/p7zip/Makefile 11 Jul 2019 21:58:04 -0000
@@ -16,9 +16,8 @@ FIX_EXTRACT_PERMISSIONS = Yes
 HOMEPAGE= http://sourceforge.net/projects/p7zip/
 
 # LGPL, except unRar plugin which is licensed as Freeware
-PERMIT_PACKAGE_CDROM-rar= no fee
-PERMIT_PACKAGE_CDROM= Yes
-PERMIT_PACKAGE_FTP= Yes
+PERMIT_PACKAGE-rar= no fee
+PERMIT_PACKAGE= Yes
 
 # uses pledge()
 WANTLIB= m pthread ${COMPILER_LIBCXX}
Index: astro/sunclock/Makefile
===================================================================
RCS file: /cvs/ports/astro/sunclock/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- astro/sunclock/Makefile 5 Jul 2019 15:43:42 -0000 1.27
+++ astro/sunclock/Makefile 11 Jul 2019 21:58:04 -0000
@@ -30,13 +30,12 @@ MULTI_PACKAGES= -main -maps
 
 .include <bsd.port.arch.mk>
 
-PERMIT_PACKAGE_CDROM-maps= no license for additional maps
-PERMIT_PACKAGE_FTP-maps= no license for additional maps
+PERMIT_PACKAGE-maps= no license for additional maps
 RUN_DEPENDS-maps= astro/sunclock
 PKG_ARCH-maps= *
 
 # GPL
-PERMIT_PACKAGE_CDROM= Yes
+PERMIT_PACKAGE= Yes
 
 WANTLIB-main= X11 Xext Xpm Xau Xdmcp c m z jpeg png
 DIST_SUBDIR= sunclock
Index: textproc/ispell/Makefile
===================================================================
RCS file: /cvs/ports/textproc/ispell/Makefile,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile
--- textproc/ispell/Makefile 17 May 2019 22:52:26 -0000 1.69
+++ textproc/ispell/Makefile 11 Jul 2019 21:58:04 -0000
@@ -64,12 +64,11 @@ MULTI_PACKAGES= -main -dutch -french -ge
 
 # ispell: BSD-like
 # dictionaries: GPL or BSD-like
-PERMIT_PACKAGE_CDROM= Yes
+PERMIT_PACKAGE= Yes
 
 WANTLIB-main= c curses
 
-PERMIT_PACKAGE_CDROM-german= no license
-PERMIT_PACKAGE_FTP-german= no license
+PERMIT_PACKAGE-german= no license
 
 RUN_DEPENDS= textproc/ispell
 RUN_DEPENDS-main=

Reply | Threaded
Open this post in threaded view
|

Re: A few words on cleaning up PERMIT_PACKAGE

Kurt Mosiejczuk-9
On Thu, Jul 11, 2019 at 06:01:14PM -0400, Kurt Mosiejczuk wrote:

> Included below is a diff to switch the multipackage Makefiles I found that
> use PERMIT_PACKAGE_*. I did not do tests/portcheck/t9/Makefile yet.

Here's a complete diff. I started with converting all instances
of PERMIT_DISTFILES_FTP to PERMIT_DISTFILES with sed. Next I hand
reconciled the places where PERMIT_PACKAGE_CDROM and PERMIT_PACKAGE_FTP
differed. Once those were done, I used sed to just convert any
remaining _CDROM lines to just PERMIT_PACKAGE and deleted any remaining
PERMIT_PACKAGE_FTP lines.

This is one massive diff. I'm attaching it in gzip'd form along with a
tarball that contains one diff for each category in ports.

--Kurt

PERMIT_PACKAGE-sweep.diff.gz (633K) Download Attachment
PERMIT-sweep.tgz (632K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few words on cleaning up PERMIT_PACKAGE

Marc Espie-2
In reply to this post by Christian Weisgerber
On Thu, Jul 11, 2019 at 11:12:14PM +0200, Christian Weisgerber wrote:

> A few words about cleaning up PERMIT_PACKAGE_*, since I've done
> similar changes before.
>
> You might think this will take care of itself over time, as ports
> are updated and modified, they'll eventually all get cleaned up.
> Past experience suggests that this won't happen or will take a very
> long time.  A subset of ports is touched frequently, but there is
> a long tail that sees no changes from one release to the next.  So,
> yeah, eventually we'll need to sit down and do an explicit cleanup
> run.
>
> You want to do this in steps and eliminate the obsolete settings from
> (1) modules and the ports that use them;
> (2) all instances of Makefile.inc and the ports that use them;
> (3) multi-package ports;
> (4) the rest, which is simple now.

This is a fairly simple change comparatively, because the tools
are aware of it and don't consider it a "binary package change", so
no revision bump is necessary.

Reply | Threaded
Open this post in threaded view
|

Re: A few words on cleaning up PERMIT_PACKAGE

Stuart Henderson
In reply to this post by Kurt Mosiejczuk-9
On 2019/07/11 18:01, Kurt Mosiejczuk wrote:
>  HOMEPAGE= http://sourceforge.net/projects/p7zip/
>  
>  # LGPL, except unRar plugin which is licensed as Freeware
> -PERMIT_PACKAGE_CDROM-rar= no fee
> -PERMIT_PACKAGE_CDROM= Yes
> -PERMIT_PACKAGE_FTP= Yes
> +PERMIT_PACKAGE-rar= no fee
> +PERMIT_PACKAGE= Yes

This one changes -rar from packages available to packages not available.

Reply | Threaded
Open this post in threaded view
|

Re: A few words on cleaning up PERMIT_PACKAGE

Kurt Mosiejczuk-9
On Fri, Jul 12, 2019 at 02:11:21PM +0100, Stuart Henderson wrote:

> This one changes -rar from packages available to packages not
> available.

Which also answers my questions about the problems with scripting
multipackages.

I'll sweep through the multipackages again.

--Kurt

Reply | Threaded
Open this post in threaded view
|

Re: A few words on cleaning up PERMIT_PACKAGE

Stuart Henderson
In reply to this post by Christian Weisgerber
On 2019/07/11 23:12, Christian Weisgerber wrote:

> A few words about cleaning up PERMIT_PACKAGE_*, since I've done
> similar changes before.
>
> You might think this will take care of itself over time, as ports
> are updated and modified, they'll eventually all get cleaned up.
> Past experience suggests that this won't happen or will take a very
> long time.  A subset of ports is touched frequently, but there is
> a long tail that sees no changes from one release to the next.  So,
> yeah, eventually we'll need to sit down and do an explicit cleanup
> run.
>
> You want to do this in steps and eliminate the obsolete settings from
> (1) modules and the ports that use them;
> (2) all instances of Makefile.inc and the ports that use them;
> (3) multi-package ports;
> (4) the rest, which is simple now.
>
> There are no modules that set PERMIT_PACKAGE_*, so that's it for
> step (1).
>
> If you want to move this forward, (2) is where we're at now.
> There are 100+ Makefile.inc files that set PERMIT_PACKAGE_*.
>
> Step (4) is very amenable to scripting.  There's really no point
> in manually changing simple ports when they can be covered by a
> script run, and it doesn't matter whether a thousand or five thousand
> are left.

What do you think about starting from the other side, moving all
the files (modules, ports, Makefile.inc) which just have a single
^PERMIT_PACKAGE_.* line which is PERMIT_PACKAGE_CDROM=Yes to
PERMIT_PACKAGE=Yes?

Then it's easier to spot the remaining oddities and work through
them.

Reply | Threaded
Open this post in threaded view
|

Re: A few words on cleaning up PERMIT_PACKAGE

Marc Espie-2
In reply to this post by Kurt Mosiejczuk-9
On Fri, Jul 12, 2019 at 09:21:53AM -0400, Kurt Mosiejczuk wrote:
> On Fri, Jul 12, 2019 at 02:11:21PM +0100, Stuart Henderson wrote:
>
> > This one changes -rar from packages available to packages not
> > available.
>
> Which also answers my questions about the problems with scripting
> multipackages.

The solution is simple: flag anything with a NO anywhere in the database.
Script everything else.