| 1 |
* Kent Fredric <kentfredric@×××××.com> wrote: |
| 2 |
> On 6/9/07, Enrico Weigelt <weigelt@×××××.de> wrote: |
| 3 |
> > |
| 4 |
> >What flexibility do I take away exactly ? |
| 5 |
> >And what exactly gets harder ? |
| 6 |
> > |
| 7 |
> |
| 8 |
> Automated building of dependant packages |
| 9 |
|
| 10 |
More precisely ? |
| 11 |
AFAICS it would be much easier w/o slots. |
| 12 |
|
| 13 |
I already mentioned "Briegel". Here I'm strictly doing as described. |
| 14 |
This works great. The only reason for using Gentoo is that it has |
| 15 |
much, much more manpower than me alone. For most common systems |
| 16 |
Gentoo is quite good, for embedded targets (where I've got relatively |
| 17 |
few packages) I'm using Briegel. |
| 18 |
|
| 19 |
> Gentoo has a collection of magic script that do make this nice for us. |
| 20 |
|
| 21 |
Which ones for example ? / What exactly do they do ? |
| 22 |
Would that magic be necessary with my approach ? |
| 23 |
|
| 24 |
> ie ( last I looked anyway ) java-config and autoconf were not binarys, |
| 25 |
> but scripts which pointed to the correct binary given the right |
| 26 |
> environment variables. |
| 27 |
> |
| 28 |
> This makes the building of other packages that were invented upstream |
| 29 |
> without predicting changes in autoconf easier to maintain, instead of |
| 30 |
> having to send out a new patch every time upstream releases a |
| 31 |
> non-compatible-with-new-autoconfs version /just/ to make it work, we |
| 32 |
> just set WANT_AUTOCONF=1.4 in the environment and the appropriate |
| 33 |
> autoconf gets run, which seeems a fairly reasonable thing to do. ( |
| 34 |
> otherwise the concept we have today known as a version bump would be a |
| 35 |
> whole deal harder more often) |
| 36 |
|
| 37 |
Yeah. Wrapper scripts. I also have such things @ Briegel. |
| 38 |
Please explain why this is an reasonable argument in the question |
| 39 |
whether or whether not to do slotting ? |
| 40 |
|
| 41 |
> I remeber the days of Java1.4 -> Java1.5 migration headaches before |
| 42 |
> they slotted it and created java-confing system to get around it, |
| 43 |
|
| 44 |
Would it make a difference if sun-java-1.5 would have got it's own |
| 45 |
package name (distinct from -1.4) ? |
| 46 |
|
| 47 |
AFAIK -1.4 and -1.5 are really incompatible, almost as much as |
| 48 |
gtk-1.x vs. gtk-2.x. So why not treating them as different packages ? |
| 49 |
|
| 50 |
> As for gtk2-0.1 vs gtk-2.0.1, the latter is clearly a more logical |
| 51 |
> version number. |
| 52 |
|
| 53 |
Why not gtk2-2.0.1 ? |
| 54 |
|
| 55 |
> if it was called gtk2 instead of gtk-2, it would need a separate |
| 56 |
> folder, and a completely different set of configs, |
| 57 |
|
| 58 |
Yes, of course - it's an different package. |
| 59 |
|
| 60 |
> it was bad enough when php4 & php5 were different applications. |
| 61 |
|
| 62 |
Why ? |
| 63 |
php4 and php5 are very incompatible, almost as much as it had been |
| 64 |
with php3. This already had been clear when php5 was at alpha. |
| 65 |
I never ever expected them to be the same package. |
| 66 |
|
| 67 |
Of course evrything would be much clearer if there was an big |
| 68 |
consensous on naming the scripts with *.php4 and *.php3 as it |
| 69 |
had been done in history w/ php3. But this really has nothing to |
| 70 |
do with slotting vs. separate packages. |
| 71 |
|
| 72 |
|
| 73 |
cu |
| 74 |
-- |
| 75 |
--------------------------------------------------------------------- |
| 76 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
| 77 |
--------------------------------------------------------------------- |
| 78 |
Please visit the OpenSource QM Taskforce: |
| 79 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
| 80 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
| 81 |
http://patches.metux.de/ |
| 82 |
--------------------------------------------------------------------- |
| 83 |
-- |
| 84 |
gentoo-user@g.o mailing list |
Archives