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 |