[gentoo-project] Introducing an optional files directory in the Portage tree with an embedded install condition and individual maintainers. (was Re: [gentoo-project] Proposal for add-on file utility (run after emerge update))

[Tom Wijsman]

On Sun, 16 Jun 2013 05:33:22 -0400
"Walter Dnes" <waltdnes@××××××××.org> wrote:

> I think the best way to avoid maintainer conflicts is to take this
> out of the hands of maintainers,

+1 I was planning to write a GLEP for a concept where optional files
would be maintained separately from packages, this could then be
covered in later revisions of the PMS so that in a reasonable time from
now we can properly support this and end to the rage and rage quits.

But you were before me, so I might as well elaborate with thoughts so
we can all end up improving the idea about how this ends up being.

Basically, what I have in mind is something along the lines of:

    Package directories get an additional directory, let's call it
    "optional", where you can put optional files in to be installed.

    eg. ${PORTDIR}/sys-apps/dbus/files/optional/
    or  ${PORTDIR}/sys-apps/dbus/optional/

    Files in this directory have a special header, it should contain a
    condition based on which to install (eg. package to be present) and
    optionally a parsable list of maintainers maintaining the package.

    (The word "file" below refers to files in the above directory,
    unless noted otherwise; just saying to avoid confusion)

    Since there is a condition based on which these files are to be
    installed, there is no need to specify such thing in the ebuild;
    this effectively separates the maintenance from the pkg maintainer.

    Since the files have their individual maintainers, different
    maintainers can maintain the file without having to maintain the
    pkg itself in question; effectively allowing you to have a
    maintainer than does _not_ want to maintain systemd whatsoever work
    on his ebuild without ever seeing systemd, whereas the developer
    that wants to contribute an optional systemd file can without a
    problem introduce it without bothering the maintainer.

    If a file does not contain a list of maintainers, it inherits the
    list of maintainers from the package; this allows the package
    maintainer itself to easily create a file without having to
    duplicate his own metadata all over the place.

    A file not containing a maintainer isn't a leeway for others to add
    themselves, files that are unmaintained should have
    maintainer-needed@g.o to prevent us from hurting the users, if bugs
    reveal a file is broken beyond repair it should be removed.

    So, there's one thing left; what about bugs filed?

    Easy, it could be made more clear in the build log which optional
    files were installed as well as list the list of maintainers for
    each optional file; that way, if the maintainers have the least
    thought that it is a problem caused by an optional file, they can
    easily assign it to those individuals maintaining that file.

    As a side benefit, optional files are separated from patches.

    What does everyone think about such approach?

> and put it in the hands of users.

-1 Not because I don't want users to be able to do this, but more
because I can't see a reasonable way for them to do this; for something
as widespread as this, there should at least be supervision. We can't
have a random user commit a random service unit for security reasons;
there has to be some kind of review, I don't see how though.

Based on that, I think the best place is the Portage tree; these files
are as small as patches, so infra and the community as a whole doesn't
really see a problem in placing it there.

> At one time there was a package of all possible systemd units that
> could be installed as one ebuild. [...SNIP...] I suggest a more
> targetted approach...

Agreed, if you don't tie them with packages, you get nasty clumps.

> * a script (or compiled program)

We can have the package managers do this instead, I think there is no
need for yet another separate script / utility to be ran; the logic
behind installing optional files that I have in mind doesn't introduce
too much complexity as far as I know.

> * that reads the output of "eix-installed -a"

We can't force such dependency; even better, we don't need such
dependency since the package manager is able to do this.

> * compares against a config file in /etc

Maybe, maybe not; I wonder if it is sufficient to just check if the
package in question is installed. Others could use INSTALL_MASK.

I mean, the percentage of people wanting to run an init script but not
its init scripts / unit files is extremely low I think; if anyone
knows of valid cases, feel free to elaborate upon them.

> * adds or deletes files based on the contents of the config file

I don't think deleting files is acceptable towards the maintainer; I
don't really see a need for this either, does anyone have an example?

>   I was originally thinking of systemd units, but this could be
> applied to initscripts or man files or info files or html docs or
> whatever.

Indeed, we should cover all optional files:

- OpenRC conf.d configuration files and init.d init scripts
- systemd service unit files, targets and similar files
- PAM files, desktop files, logrotate files, cron files, bash completion
- ...

> In addition to pulling in standard stuff, it could pull in
> custom units or docs from "personal overlay" sources.  It would
> usually be run once, right after an update.

When you let the PM do this, this is almost automatically covered.

>   IANACP (I Am Not A C Programmer), so I would probably do this in
> bash if I did it strictly for personal use.

I think I've repeated it enough above, this is more trivial in the PM.

> But I'm beginning to wonder if it might be a useful approach resolve
> some conflicts between various groups of users/developers.

Definitely, by designing an approach that uses a separate directory in a
package, you assign maintainers to individual files like eclasses do.

> end-users could easily customize their systems' *REGARDLESS OF HOW
> DEVELOPERS SET UP EBUILDS*.

Indeed, given the defined structure, users can hack things together.

> This might require a "systemd units herd" to supply a tarball with
> systemd units that would be selectively installed.  And possibly a
> "documentation herd", etc.

Without going to a specific example, some existing herds cover this.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D