| 1 |
Richard Fish wrote: |
| 2 |
|
| 3 |
--snip |
| 4 |
> It is far more likely that you could break python (and thus portage) |
| 5 |
> from a mishandled gcc or glibc update. But there is already a |
| 6 |
> recovery option available in this case; if you have buildpkg in your |
| 7 |
> FEATURES, you will already have a backup copy of |
| 8 |
> portage/python/gcc/glibc/everything else in $PKGDIR. Even if portage |
| 9 |
> is broken, you can extract those tarballs to get back to a working |
| 10 |
> configuration. Of course, this assumes that tar and bzip2 |
| 11 |
> work...otherwise you are down to booting from a live CD. |
| 12 |
--snip |
| 13 |
Well, correct me if I'm wrong but it think it's not quite true. |
| 14 |
|
| 15 |
I *think* if you have buildpkg in your FEATURES, you will |
| 16 |
get binary packages in your $PKGDIR with the new, updated versions. |
| 17 |
Those that you have just emerged , not the previous ones which you |
| 18 |
would like to have backed up. Having the newly compiled packages |
| 19 |
$PKGDIR can be exported via http server as an alias for example: |
| 20 |
"alias /packages /usr/portage/packages" |
| 21 |
and used as PORTAGE_BINHOST="http://192.168.0.1/packages |
| 22 |
in /etc/make.conf on a buch of other machines. This way one doesn't |
| 23 |
compile on every single machine but use the already compiled packages. |
| 24 |
Very useful if you have many equal (as hardware) machines with the |
| 25 |
same settings in "make.conf". |
| 26 |
The only way (I'm aware of) to make a semiautomatic backup of |
| 27 |
an already installed package is to use "qpkg" |
| 28 |
"qpkg" is available in "app-portage/gentoolkit" |
| 29 |
|
| 30 |
|
| 31 |
On the subject. |
| 32 |
|
| 33 |
I would say that I like end use Gentoo for two main reasons: |
| 34 |
1) it is a binary distro, which means optimization, customization and speed. |
| 35 |
2) gentoo doesn't mess with MY config settings without asking if it should. |
| 36 |
I would hate if some automated tool is ****ing MY settings without my |
| 37 |
knowledge. |
| 38 |
|
| 39 |
About the "damaged portage" issue...well, I agree with others who think it |
| 40 |
is highly unlikely a damaged version to go out and get available for |
| 41 |
the users. |
| 42 |
|
| 43 |
My "wish list" |
| 44 |
1) I would like to see an implementation of "PAUSE". I mean, during most |
| 45 |
of the emerges there is not only one package to be emerged. Some of the |
| 46 |
packages have instructions for additional post installation steps that |
| 47 |
the user |
| 48 |
should take. Well, I think there should be a "FETURE", a flag to |
| 49 |
"emerge" or |
| 50 |
some other mechanism to tell portage to wait for confirmation if the ebuild |
| 51 |
gives such information. |
| 52 |
2) More control over portages verbosity. Most of the time I only need to see |
| 53 |
the portages messages, not all the compilation stuff. The later is |
| 54 |
interesting |
| 55 |
to me only if the compilation fails. |
| 56 |
3) I hate ebuilds that are rewriting variables that I have set. For |
| 57 |
example I |
| 58 |
couldn't find a way to compile mplayer with |
| 59 |
"--disable-runtime-cpudetection", |
| 60 |
many packages overwrite C(XX)FLAGS. They change "-O3" to "-O2" etc. |
| 61 |
"Gentoo is about choices" but why this happens? My opinion is that portage |
| 62 |
should warn about the "too aggressive setting" but to let ME chose to change |
| 63 |
the settings or not. |
| 64 |
|
| 65 |
|
| 66 |
|
| 67 |
-- |
| 68 |
Best regards, |
| 69 |
Daniel |
| 70 |
|
| 71 |
-- |
| 72 |
gentoo-user@g.o mailing list |
Archives