| 1 |
Riyad Kalla wrote: |
| 2 |
> Good point... doesn't this require the creation/maintenance of hundreds |
| 3 |
> of new ebuilds? |
| 4 |
|
| 5 |
perhaps using eclass could reduce the body of the ebuild to a standard |
| 6 |
template |
| 7 |
which can be easly maintained ? |
| 8 |
|
| 9 |
> |
| 10 |
> |
| 11 |
>>-----Original Message----- |
| 12 |
>>From: Dylan Carlson [mailto:absinthe@×××××.com] |
| 13 |
>>Sent: Tuesday, January 28, 2003 3:34 AM |
| 14 |
>>To: sh@×××××××××.de; gentoo-dev@g.o |
| 15 |
>>Subject: Re: [gentoo-dev] Split KDE packages? |
| 16 |
>> |
| 17 |
>> |
| 18 |
>>On Monday 27 January 2003 10:57 pm, Stephan Hermann wrote: |
| 19 |
>> |
| 20 |
>>>I don't think this is a good idea. |
| 21 |
>>>On RedHat distribution you got this foolish system (of |
| 22 |
>> |
| 23 |
>>course binary |
| 24 |
>> |
| 25 |
>>>packages). You don't know which application is in the normal kde |
| 26 |
>>>distribution or just a plain application like whatever. |
| 27 |
>>> |
| 28 |
>>>If you see kde as one complete desktop enviroment, then you |
| 29 |
>> |
| 30 |
>>let kde as |
| 31 |
>> |
| 32 |
>>>is (compiling all applications in one package the same time), there |
| 33 |
>>>aren't a lot of patches for kde in the last few months, so |
| 34 |
>> |
| 35 |
>>we can live |
| 36 |
>> |
| 37 |
>>>with it as is. |
| 38 |
>> |
| 39 |
>>You're arguing against something I don't think you understand at all. |
| 40 |
>> |
| 41 |
>>If KDE were broken out to smaller ebuilds, there would still |
| 42 |
>>be a master |
| 43 |
>>ebuild to bring them all together as one bundle, so therefore |
| 44 |
>>users would |
| 45 |
>>not have to remember what pieces make up a complete KDE bundle. |
| 46 |
>> |
| 47 |
>>The end result would be absolutely no different. People who |
| 48 |
>>want the whole |
| 49 |
>>KDE bundle would still get the whole KDE bundle installed the |
| 50 |
>>same as it |
| 51 |
>>would be otherwise. |
| 52 |
>> |
| 53 |
>>What it gives us is the ability to update one small piece of |
| 54 |
>>KDE without |
| 55 |
>>having to update and recompile the whole thing in the event |
| 56 |
>>of a patch. |
| 57 |
>>And between releases there are in fact a ton of patches that go out. |
| 58 |
>> |
| 59 |
>>The only reason this hasn't been done already is because |
| 60 |
>>there isn't any |
| 61 |
>>obvious solution to get around the increase in compile time |
| 62 |
>>-- which is a |
| 63 |
>>result of having ./configure run over and over for each |
| 64 |
>>separate ebuild. |
| 65 |
>> |
| 66 |
>>Once that's eliminated or mitigated, the users wouldn't know any |
| 67 |
>>difference. But I guarantee everyone would know the |
| 68 |
>>difference when it |
| 69 |
>>comes time to patch KDE up for inevitable serious bugs or |
| 70 |
>>security flaws. |
| 71 |
>> |
| 72 |
>>It would save a lot of people a lot of download and recompile |
| 73 |
>>time if it's |
| 74 |
>>between major.minor release versions. |
| 75 |
>> |
| 76 |
>>Cheers, |
| 77 |
>>Dylan Carlson [absinthe@×××××.com] |
| 78 |
>> |
| 79 |
>>-- |
| 80 |
>>gentoo-dev@g.o mailing list |
| 81 |
>> |
| 82 |
> |
| 83 |
> |
| 84 |
> |
| 85 |
> -- |
| 86 |
> gentoo-dev@g.o mailing list |
| 87 |
> |
| 88 |
|
| 89 |
|
| 90 |
|
| 91 |
-- |
| 92 |
gentoo-dev@g.o mailing list |
Archives