[BRAINSTORMING] simplifying maintainer's life

[Tijl Coosemans]

On Wed, 03 Sep 2014 16:06:21 -0500 Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> On 9/3/2014 1:57 PM, Bryan Drewery wrote:
> > What might be interesting is an autoplist with glob-like syntax to
> > support sub-packages. So a main package could be everything except
> > .debug, or .h, or man/*. Or each of those prefixed with a keyword
> > specifying with package they are in.
> 
> It may be tricky to handle the current ignore mechanism of @comment. I
> laid out ideas for this before. Here is my previous proposal which had
> separate plist files for sub-packages. The general idea could be adapted
> to other ways of specifying patterns/lists for sub-packages though:
> 
> All plists are packaged and then anything leftover is packaged into
> the main package assuming there is not a plist for it specifying
> what to install.  Orphans would only be things not in any plist.
> So if you specify a main plist then you are forbidden to have
> orphans, not specifying a plist would have no orphans as everything
> is installed from stagedir.
> 
> 
> 1. No plists = everything in STAGEDIR is automatically added to a plist.
>    (I suppose this ignores all the cruft in Mk/* that adds to plists)
> 2. pkg-plist = "main" plist, If you only have this file then any orphans
>    are fatal.
> 3. pkg-plist, pkg-plist.docs, main package and doc package, any orphan
>    not in one of these plists is fatal. "doc" is arbitrary here, you can
>    have N plists.
> 4. pkg-plist.ignore contains files not to install and not to consider
>    orphans. One could argue that "ignore" here really should be a
>    subpackage of the ignored files. I.e., why are they ignored? Should
>    it really just be another subpackage? But "ignore" can be a special
>    case to really ignore and not package.
> 
> This scheme gives us autoplist, a way to ignore orphans you know don't
> matter, and properly alerts when new files are added in new releases.

An important type of files to list explicitly are libraries, because
you need to know when a library version changes so you can bump
PORTREVISION on dependent ports.  I don't think it's safe to rely on
the pkg repo to give you that information because there may not always
be a previous package (for whatever reason).

In your proposal either you have autoplist or you list everything.
This means that if you have to list some files like libraries you
cannot have autoplist.  With glob patterns you can have at least a
partial autoplist.  It is more gradual.

This issue would go away of course if we had a 'make dependents' target
that rebuilds installed packages that depend on a given port.  If this
target ran automatically when a library version change was detected there
would no longer be a need to bump PORTREVISION.  However, this makes the
time it takes to update a port (or how many other ports it triggers)
unpredictable.

For subpackages I would suggest something like:

these/files/go
into/main/package
@subpackage S1
these/will/go
into/S1/package
@subpackage S2
this/goes/into/S2
@subpackage
this/goes/back/into/main

It may be convenient to also have a shorthand like the new
(owner,group,mode)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140904/848ca339/attachment.sig>