Gentoo Archives: gentoo-dev

From: Andrew Savchenko <bircoph@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [RFD] Adopt-a-package, proxy-maintenance, and other musings
Date: Sat, 23 Jan 2016 19:54:28
Message-Id: 20160123225401.586d25a183181a1d240432fa@gentoo.org
In Reply to: Re: [gentoo-dev] Re: [RFD] Adopt-a-package, proxy-maintenance, and other musings by Ian Delaney
1 On Sat, 23 Jan 2016 21:04:56 +0800 Ian Delaney wrote:
2 > On Tue, 19 Jan 2016 22:02:21 -0500
3 > Göktürk Yüksek <gokturk@××××××××××.edu> wrote:
4 >
5 > > Duncan:
6 > > > NP-Hardass posted on Tue, 19 Jan 2016 00:44:49 -0500 as excerpted:
7 > > >
8 > > [...]
9 > > >
10 > > > That gave me the idea of a maintainer-needed eclass. When packages
11 > > > are set to maintainer-needed, they can simply inherit this eclass
12 > > > and add whatever function to the pkg_postinst, that will add a
13 > > > message that will in effect say "adopt-me please", probably
14 > > > printing a proxy-maintainer invitation URL to go to for more
15 > > > information.
16 > > >
17 > > > Talking about pkg_postinst messages, unless I missed it there's no
18 > > > simple way to add a one ATM, without coding up the whole function,
19 > > > making it problematic for eclasses, etc. For EAPI-7, what about
20 > > > either a helper function that can be called, or an array variable
21 > > > that can be simply added to, that simply adds the supplied message
22 > > > to a list of messages printed at pkg_postinst time, and of course
23 > > > an appropriate default_pkg_postinst to go along with it? Then
24 > > > ebuilds and eclasses can call this helper or set this var in
25 > > > whatever phase they need to, and the message will be printed at
26 > > > pkg_postinst time without having to worry about setting up your own
27 > > > pkg_postinst or stepping on anything pkg_postinst related setup
28 > > > elsewhere.
29 > > See:
30 > > sys-apps/portage: show an elog message when merged package is
31 > > maintained by maintainer-needed
32 > > https://bugs.gentoo.org/show_bug.cgi?id=398633
33 > >
34 > > Can we reconsider implementing this idea perhaps?
35 > >
36 >
37 > Given the thrust of this whole discussion this is a good idea. It
38 > naturally advertises packages of this unmaintained status to users as
39 > they emerge.
40
41 Please make this optional. Elog already contains too much
42 information and it is already hard to read logs after world update
43 or other massive change. It literally takes hours sometimes.
44
45 Best regards,
46 Andrew Savchenko

Replies