Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Sep 2014 16:48:08 +0100
From:      Dreamcat4 <dreamcat4@gmail.com>
To:        Baptiste Daroussin <bapt@freebsd.org>
Cc:        ports@freebsd.org
Subject:   Re: First step (Re: [BRAINSTORMING] simplifying maintainer's life)
Message-ID:  <CAN39uToCu4V0qKn2Hx2-jmj=z0M2u84eOn4TwYjO0zW4gvOyWQ@mail.gmail.com>
In-Reply-To: <20140905081911.GB25840@ivaldir.etoilebsd.net>
References:  <20140903082538.GE63085@ivaldir.etoilebsd.net> <20140905081911.GB25840@ivaldir.etoilebsd.net>

next in thread | previous in thread | raw e-mail | index | archive | help
And for the documentation. Porter's handbook, it needs changes?

On Fri, Sep 5, 2014 at 9:19 AM, Baptiste Daroussin <bapt@freebsd.org> wrote:
> After the discussion that happened here is what I think we should do
> If no stong objections are raised thise this will happen in pkg 1.3.8
>
> - Ignore mtree in packages
> - Automatically handle directory removal for any directory under PREFIX
> - Introduce @dir (in fact already there) for directories with special care:
>   * empty directories
>   * directories with special credential (@dir(user,group,mode))
> - Consider directories out of PREFIX as special hence needing to be listed with
>   @dir
>
> @dirrmtry and @dirrm will be considered changed into aliases for @dir but remain
> for compatibility (with a warning if DEVELOPER_MODE is set)
>
> - the possibility to accept regular plist entry as directories will be in but
>   disable by default, allowing vendors to rely on it if they do want but leaving
>   the ports tree not accepting them (that clarifies a lot what the the plist for
>   maintainers)
>
> - automatic plist is postponed for later as there is no concensus and it will
>   require lots of work to be able to provide a minimum set on fonctionnality
>   that are important for maintainers:
>   * having some sort of pkg filesearch to find what do provide a given
>     file/header
>   * being able to store what is the expected normal content of the package so a
>     builder can raise an error is something goes wrong (this can become really
>     tricky, given all possible options and so on)
>
> Other proposals are not rejected at all, there was sure interesting ones with
> nice design proposed, but that will be too intrusive for pkg 1.3.x as designed
>
> regards,
> Bapt



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN39uToCu4V0qKn2Hx2-jmj=z0M2u84eOn4TwYjO0zW4gvOyWQ>