1 |
On Fri, Oct 30, 2015 at 1:39 AM, Michał Górny <mgorny@g.o> wrote: |
2 |
> On Thu, 29 Oct 2015 21:06:33 -0700 |
3 |
> Brian Dolbec <dolsen@g.o> wrote: |
4 |
> |
5 |
>> On Thu, 29 Oct 2015 17:37:26 -0400 |
6 |
>> Mike Frysinger <vapier@g.o> wrote: |
7 |
>> |
8 |
>> > On 22 Oct 2015 12:54, Paul Varner wrote: |
9 |
>> > > Mike, I know you're busy with other stuff, but if you ever want to |
10 |
>> > > see a new gentoolkit/gentoolkit-dev release, consider this your |
11 |
>> > > authorization to just do it. The README.dev files state how to |
12 |
>> > > make releases. |
13 |
>> > |
14 |
>> > thanks, i think this will help a lot |
15 |
>> > |
16 |
>> > > Since, the tools have dwindled down in gentoolkit-dev, I do think it |
17 |
>> > > does make sense to keep it in the same repo and merge the packages |
18 |
>> > > together behind a USE flag. I will revert the commit, that emptied |
19 |
>> > > the genttolkit-dev branch and ask mgorny to nuke the new |
20 |
>> > > gentoolkit-dev repository. |
21 |
>> > > |
22 |
>> > > As I get time, I will work towards moving the gentoolkit-dev tools |
23 |
>> > > into gentoolkit and putting them behind a USE flag in the ebuild. |
24 |
>> > |
25 |
>> > i'm no distutils expert, and every time i try to do something "fancy", |
26 |
>> > i get frustrated by the module :). do people know of examples where |
27 |
>> > you can do optional installs with a flag ? a cookbook sort of entry |
28 |
>> > here would help and i could take care of merging in say ekeyword. |
29 |
>> > -mike |
30 |
>> |
31 |
>> Have a look at layman's setup.py. It parses IUSE to set the installed |
32 |
>> files via setup.py. It may not be the best method, but it does work. |
33 |
>> |
34 |
>> The layman ebuild sets deps acording to the ISUE flags and setup.py |
35 |
>> sets the installed modules on the python side. |
36 |
> |
37 |
> Sorry, what?! That's a huge QA violation. There is *NO* guarantee that |
38 |
> USE will be exported. In fact, it is only exported because of poor |
39 |
> design inside Portage that could result in the variable getting lost |
40 |
> otherwise. |
41 |
|
42 |
PMS says that USE will be exported to the environment. So, this should |
43 |
not break with any PMS-compliant package manager. |
44 |
|
45 |
Personally, it makes me cringe, but I suppose it doesn't make a lot of |
46 |
sense to invent an entirely new envvar for it. |