| 1 |
Vaeth wrote: |
| 2 |
> Ciaran McCreesh wrote: |
| 3 |
>> Having to write an ebuild just to install something in a package manager |
| 4 |
>> friendly way and be able to uninstall it cleanly later is a defect |
| 5 |
> |
| 6 |
> No, this is exactly what ebuilds meant for: That the package manager |
| 7 |
> keeps track of your package, and possibly also recompiles it in case |
| 8 |
> of library upgrades. For this reason, ebuilds should essentially just |
| 9 |
> consist of the commands which you would also type in the shell - this |
| 10 |
> information *must* be provided (together with obviously some data like |
| 11 |
> package name, slot-requests, and an otional description), but essentially |
| 12 |
> that should be it. |
| 13 |
> If it is more work or requires more knowledge to write an ebuild, then |
| 14 |
> it is the ebuild concept which is defect. |
| 15 |
> |
| 16 |
So in your opinion, a future eapi should make ebuilds look closer to this? |
| 17 |
http://aur.archlinux.org/packages/mplayer/mplayer/PKGBUILD |
| 18 |
|
| 19 |
Importare is a very useful and nice tool. |
| 20 |
I don't understand, that Portage doesn't have something like that, yet. |
| 21 |
(So they should consider doing something like that.) |
| 22 |
When I was still using Gentoo, I did a lot of ebuilds for programs which |
| 23 |
I found out, that they don't work afterwards. |
| 24 |
Using package.provide isn't really nice either, because it then isn't |
| 25 |
tracked. |
| 26 |
With importare, I can first test it, and if it works, make an |
| 27 |
ebuild/exheres and install that. |
| 28 |
If you do that, it will automatically upgrade the importare'd package |
| 29 |
and uninstall any leftovers, just like a normal update. |
| 30 |
|
| 31 |
BTW, it is not a PM replacement, it is an addition. |
| 32 |
You would be considered to be mad if you use importare for everything. |
| 33 |
|
| 34 |
Regards, |
| 35 |
Bernd |
Archives