1 |
On Thu, Sep 22, 2005 at 11:26:19AM +0300, Philippe Trottier wrote: |
2 |
> Daniel Ostrow wrote: |
3 |
> > On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote: |
4 |
> > |
5 |
> >>Hi everybody, |
6 |
> >> |
7 |
> >>If it's commercial, the company in question should (and must) allow an |
8 |
> >>ebuild for is product, like what happens with rpms and other packages. |
9 |
> >>Adding commercial ebuilds to portage is like tainting the kernel with |
10 |
> >>binary drivers. |
11 |
> >> |
12 |
> >>Maybe a better solution comes with gensync? If companies want ebuilds, |
13 |
> >>sure. They go to the "commercial" portage. Hell, even put a price on |
14 |
> >>maintaining those ebuilds. |
15 |
> >> |
16 |
> >>Remember that are a lot of people that don't want to use that kind of |
17 |
> >>software. There are people that doesn't have even xorg and have to |
18 |
> >>sync all the ebuilds from portage. |
19 |
> > |
20 |
> > This is what rsync excludes are for...there is no good reason to remove |
21 |
> > things like doom3 and UT2k4 from the tree for the sole reason that they |
22 |
> > are commercial packages. You don't want them...fine...exclude them. |
23 |
> > |
24 |
> |
25 |
> Possible to make the default a non-commercial ebuild rsync ? The exclude |
26 |
> file for rsync should be easy to make. That would be convenient for all |
27 |
> and allow purist to keep their system clean. Also would allow coders to |
28 |
> know what are the GNU weakest tools and work on them. |
29 |
|
30 |
The rsync exclude list would be rather massive, and would require |
31 |
modification to the rsync generation. Also results in cvs users |
32 |
having a different tree then what those rsync'ing would get (not good |
33 |
imo). |
34 |
|
35 |
GLEP23's accept_license is (for me) the preferred solution; you have |
36 |
everything locally, the choice of what you use is yours (rather then a |
37 |
default upstream with a secondary repo of commercial). |
38 |
|
39 |
~harring |