| View previous topic :: View next topic |
| Author |
Message |
bell
Guru
Joined: 27 Nov 2007
Posts: 514
|
 Posted: Mon Apr 28, 2008 11:57 am Post subject: Änderungen an Ebuilds ohne Versionsänderung |
 |
|
Hallo Leute,
ich habe vor kurzem festgestellt, dass Stable-Ebuilds geändert werden, ohne dass die Versionsnummer hoch gezählt wird. Das hat dann zur Folge, dass je nachdem an welchem Tag man eine Software installiert hatte, diese anders installiert wird oder einen anderen Stand hat. Aufgefallen ist es mir insbesondere am openoffice-2.4, wo sogar ein Update auf ooo-build-2.4.0.8 durchgeführt wird, ohne dass sich die Ebuild-Version ändert.
Ich habe in Skript erstellt, mit dem man die installierte Pakete überprüfen kann:
| Code: | #!/bin/bash
PKGDIR=/var/db/pkg
PORTDIR=/usr/portage
TMPDIR=/tmp
typeset -i IINSTALLED
typeset -i INOTFOUND
typeset -i IOK
typeset -i INOK
cleanup(){
cat $1 \
| grep -v '# $Header:' \
| grep -v 'KEYWORDS=' \
| sed 's/#.*//g' \
| grep -v 'HOMEPAGE=' \
| grep -v 'eerror' \
| grep -v 'einfo' \
| grep -v 'ewarn' \
| grep -v 'elog' \
| grep -v ^$
}
for EINSTPATH in $(find $PKGDIR -name \*.ebuild); do
CATEGORY=$(echo $EINSTPATH | sed 's#\(^/var/db/pkg/\)\(.*\)\(/.*/.*\)#\2#g')
EBUILDNAME=$(echo $EINSTPATH | sed 's#^/var/db/pkg/.*/.*/##g')
PACKNAME=$(echo $EINSTPATH | sed 's#\(^/var/db/pkg/.*/\)\([a-zA-Z0-9]*\)\(.*\)#\2#g')
ENEWPATH=$PORTDIR/$CATEGORY/$PACKNAME*/$EBUILDNAME
IINSTALLED=IINSTALLED+1
if [ -e $ENEWPATH ]; then
OLD=$(cleanup $EINSTPATH)
NEW=$(cleanup $ENEWPATH)
if [ "$OLD" == "$NEW" ] ; then
IOK=IOK+1
else
echo =$CATEGORY/$EBUILDNAME | sed 's/.ebuild//g'
INOK=INOK+1
if [ "$1" == '-v' ]; then
echo "$OLD" > $TMPDIR/oldebuild
echo "$NEW" > $TMPDIR/newebuild
diff $TMPDIR/oldebuild $TMPDIR/newebuild
fi
fi
else
INOTFOUND=INOTFOUND+1
fi
done
if ! [ "$1" == '-q' ]; then
echo "Installed: $IINSTALLED Notfound: $INOTFOUND OK: $IOK Not OK: $INOK"
fi |
Mit dem Parameter -v kann man sich gleich die entprechenden Diffs anzeigen lassen.
Mit dem Parameter -q wird die Summenzeile ausgeblendet, so dass
| Code: | | emerge -va1 $(./checkmodebuilds.sh -q) |
möglich ist.
Wie in cleanup() zu sehen ist, ignoriert das Skript bereits einige Änderungen, die auf das Build-Verhalten keine Auswirkung haben. Jedoch ist die übrig bleibende Prozentzahl von 16% an versteckt geänderten Ebuilds bei meinem ein Jahr altem Testsystem, welches wöchentlich aktualisiert wird, zu hoch.
Gibt es eine Richtlinie, wann die Änderungen erlaubt sind und wann die Version hochgezählt werden muss? |
|
| Back to top |
|
 |
Carlo
Developer
Joined: 12 Aug 2002
Posts: 3356
|
| Posted: Mon Apr 28, 2008 12:52 pm Post subject: |
|
|
Kosmetische Änderungen, die sich nicht auf das Kompilat auswirken oder anderweitig zur Laufzeit bemerkbar machen, sind immer erlaubt. Darberhinaus gehende Änderungen sind spätestens bei stabil markierten Ebuilds inakzeptabel. Ja, es wurde und wird gelegentlich gegen die Ebuild Policy verstoßen. Wenn dir dies auffällt, mach bitte einen Bug auf; Solches Fehlverhalten wird leider zu selten sanktioniert.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs. |
|
| Back to top |
|
|
bell
Guru
Joined: 27 Nov 2007
Posts: 514
|
| Posted: Mon Apr 28, 2008 1:17 pm Post subject: |
|
|
| Quote: | | Kosmetische Änderungen, die sich nicht auf das Kompilat auswirken oder anderweitig zur Laufzeit bemerkbar machen, sind immer erlaubt. Darberhinaus gehende Änderungen sind spätestens bei stabil markierten Ebuilds inakzeptabel |
Genau davon bin ich ausgegangen btw. bin genau dieser Meinung. Jedoch hatte ich mit meinem Skript 116 modifizierte Ebuilds gefunden. Selbst wenn bei genauer Betrachtung die Hälfte davon Ok ist, müsste ich so um die 50 Bug-Reports schreiben. Daher denke ich, dass das Problem globaler angegangen werden sollte. Automatische QA Überprüfung vielleicht?
Leider ist mein Englisch nicht soweit, dass ich eine Diskussion auf gentoo-dev dazu führen könnte. Ich bin auch nicht mit Gentoo-Entwicklungs-Prozessen vertraut. Daher wollte ich erstmal hier auf das Problem aufmerksam machen. Mit dem Skript kann auch jeder das Problem nachvollziehen. Eventuell könnte ja jemand das ganze an das dev-Team herantragen.
Als Zwischenlösung bietet sich das | Code: | | emerge -va1 $(./checkmodebuilds.sh -q) |
an, für Leute, die ihr System "wirklich" aktuell halten wollen. |
|
| Back to top |
|
|
Carlo
Developer
Joined: 12 Aug 2002
Posts: 3356
|
| Posted: Mon Apr 28, 2008 5:01 pm Post subject: |
|
|
| bell wrote: | | Selbst wenn bei genauer Betrachtung die Hälfte davon Ok ist, müsste ich so um die 50 Bug-Reports schreiben. Daher denke ich, dass das Problem globaler angegangen werden sollte. Automatische QA Überprüfung vielleicht? |
Automatische Qualitätsprüfungen funktionieren nur sehr eingeschränkt, da es nur schwer möglich ist, gültige und ungültige Änderungen auseinanderzuhalten. Nimm zum Beispiel nachträglich geänderte Patches: Wenn ein verändertes, zur Installation benötigtes Skript, obwohl für /bin/sh geschrieben, plötzlich nur noch mit Bash funktioniert, rechtfertigt der Fix keine Revisionsänderung des Ebuilds. Selbiges gilt für fehlerhafte Testskripte.
Im Grunde hilft nur, Leute entsprechend zu instruieren und gegebenenfalls an den Hammelbeinen zu ziehen. Manches dreht sich leider um Befindlichkeiten, Meinungen etc. und im Zweifel gehen die Leute einfach, wenn sie eine Kleinigkeit nicht durchsetzen können oder sich sonstwie gemobbt fühlen, was angesichts der dürtigen Personaldecke auch nicht weiterhilft. Und solange wirklich gute, langjährige Gentoo-Devs sich gelegentlich derartige Verfehlungen erlauben, obwohl gerade sie als Vorbild fungieren sollten, ist da Hopfen und Mals verloren. Ein implizites Druckmittel, Menschen auf Linie zu bringen, wie der Gehaltsscheck, existiert im Rahmen einer Community-Distro nunmal nicht.
| bell wrote: | | Ich bin auch nicht mit Gentoo-Entwicklungs-Prozessen vertraut. Daher wollte ich erstmal hier auf das Problem aufmerksam machen. Mit dem Skript kann auch jeder das Problem nachvollziehen. |
Wenn sich da einige aus der Nutzerschaft finden würden, die gesammelten Daten statstisch etwas aufmotzten, häßliche Beispiele raussuchten und dann die gentoo-dev Mailing-Liste damit belästigten, wäre das nicht verkehrt.
| bell wrote: | | Eventuell könnte ja jemand das ganze an das dev-Team herantragen. |
Könnte. Ich habe die Erfahrung gemacht, daß der Gedanke der Qualitätssicherung sehr verschieden interpretiert wird und derzeit keine Lust, mich anflamen zu lassen, weil plötzlich ein Finger in der Wunde liegt.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs. |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9625
Location: beyond the rim
|
| Posted: Mon Apr 28, 2008 5:49 pm Post subject: |
|
|
| Carlo wrote: | | Darberhinaus gehende Änderungen sind spätestens bei stabil markierten Ebuilds inakzeptabel. |
Stimmt so pauschal nicht, das ist immer eine Frage der Verhältnismäßigkeit.
| Quote: | | Ja, es wurde und wird gelegentlich gegen die Ebuild Policy verstoßen. |
| Ebuild Policy wrote: | | Package revision numbers should be incremented by Gentoo Linux developers when the ebuild has changed to the point where users would want to upgrade. Typically, this is the case when fixes are made to an ebuild that affect the resultant installed files, but the ebuild uses the same source tarball as the previous release. If you make an internal, stylistic change to the ebuild that does not change any of the installed files, then there is no need to bump the revision number. Likewise, if you fix a compilation problem in the ebuild that was affecting some users, there is no need to bump the revision number, since those for whom it worked perfectly would see no benefit in installing a new revision, and those who experienced the problem do not have the package installed (since compilation failed) and thus have no need for the new revision number to force an upgrade. A revision bump is also not necessary if a minority of users will be affected and the package has a nontrivial average compilation time; use your best judgement in these circumstances. |
|
|
| Back to top |
|
|
bell
Guru
Joined: 27 Nov 2007
Posts: 514
|
| Posted: Tue Apr 29, 2008 7:18 am Post subject: |
|
|
Ok, ich sehe, dass die Situation ein Kompromiss zwischen Aktualität und möglichst wenigen Re-Emerges ist. Dennoch gibt es hierzu unterschiedliche Ansichten, also wäre es sinnvoll, den Usern eine Möglichkeit an die Hand zu geben, selbst zu entscheiden, wie aktuell sie das System halten und wie viele Re-Emerges akzeptabel sind. Ich denke da an einen weiteren Emerge-Parameter. Z.Z. haben wir ja schon mehrere Stufen:
1. emerge -u world <- Keine Re-emerges, nicht alle Versionsänderungen werden übernommen
2. emerge -uD world <- Keine Re-emerges, alle Versionsänderungen werden übernommen
3. emerge -uDN world <- Reemerges bei Änderung der Use-Flags auch ohne Versionsänderung
Es könnten also noch zwei weitere Stufen hinzukommen, z.B.:
4. emerge -uDNx world <- Alle Ebuilds mit Änderungen, die nicht in einer Blacklist definiert sind (z.B. HOMEPAGE=), werden re-emerged
5. emerge -uDNX world <- Alle geänderten Ebuilds werden neu emerged, unabhängig, ob es sinnvoll ist oder nicht.
Zum Schluss haben wir ja auch noch
6. emerge -e world <- Alle Pakete werden neu emerged, unabhängig davon, ob sich irgendwas geändert hat.
Ich denke, mit diesem Vorschlag kann man dem Problem besser begegnen, da keinen Devs irgendwas vorgeworfen wird, sondern die User weitere Optionen/Möglichkeiten erhalten.
Bevor ich mich an ein FT-Request setze, würde mich Eure Meinung dazu interessieren. |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Tue Apr 29, 2008 7:24 am Post subject: |
|
|
keine direkte Supportfrage, daher moved from Deutsches Forum (German) to Diskussionsforum.
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
Necoro
Veteran
Joined: 18 Dec 2005
Posts: 1912
Location: Germany
|
| Posted: Tue Apr 29, 2008 8:57 am Post subject: |
|
|
| bell wrote: | | 4. emerge -uDNx world <- Alle Ebuilds mit Änderungen, die nicht in einer Blacklist definiert sind (z.B. HOMEPAGE=), werden re-emerged |
Ich glaube nicht, dass das machbar ist... denn du müsstest die Änderungen irgendwo entweder protokollieren oder zur Laufzeit rausfinden. Ersteres ist an sich einfach, aber in meinen Augen Overkill. Das andere wäre ja eigentlich nur möglich durch diff $ebuild_in_vdb $ebuild_im_portagetree - das für jedes installierte ebuild zieht dir die Performance in den Keller.
Außerdem: Wie willst du die Blacklist definieren? - Woran willst du sehen, ob eine Änderung in zB src_compile nur ein Kommentar hinzufügt, oder richtig was ändert. - Aber vielleicht ändert es auch nur was, was für deine Architektur/Useflag-Konstellation unwichtig ist... Und was ist mit Änderungen in einer eclass? - Willst du denn alle betroffenen ebuilds neu bauen? (Ich fände an dieser Stelle die Versionierung von eclasses wichtiger  )
Ich plädiere darauf, auf den Common Sense der Ebuild-Devs zu vertrauen, die an den richtigen Stellen einen Revbump durchführen
_________________
Inter Deum Et Diabolum Semper Musica Est. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Apr 29, 2008 8:58 am Post subject: |
|
|
Ich würde das nicht von einem Portage-Feature abhängig machen wollen, denn z.B. Änderungen an files/*-Daten bekommt man so nicht mit.
Vielmehr wäre es m.E. sinnvoll, die Revision-Nummer dreipunktig zu gestalten: Die letzte Nummer sollte sich bei jeder Änderung des Ebuilds ändern (egal wie trivial - dies könnte sogar automatisiert passieren), die zweite bei jeder Ebuild-Änderung, die über das Ändern der Metadaten und Fixen von Typos in einfo/elog hinaus führt (insbesondere bei jeder Änderung von Daten in files/* für die betroffenen Versionen, egal wie trivial).
Dies hätte bei einigen Bug-Reports den Vorteil, dass man genau weiss, auf welches Ebuild und welche Version von files/* sich eine Beschreibung bezieht, und für den Benutzer läge der Vorteil darin, dass er mit Tools wie diff-eix (wenn sie entsprechend erweitert würden) auf solche Änderungen aufmerksam gemacht werden kann. Beispielsweise muss ich zur Zeit - da ich gerade auf gcc-4.3 umstelle - nach jedem Syncen mit einem Script den Baum nach gcc-4.3-Fixes absuchen, weil ich die sonst nicht mitbekomme (sinnvollerweise ziehen diese ja meistens keine -r*-Änderung nach sich).
Aber diese Vorschläge sind alle schon gemacht worden... |
|
| Back to top |
|
|
bell
Guru
Joined: 27 Nov 2007
Posts: 514
|
| Posted: Tue Apr 29, 2008 9:25 am Post subject: |
|
|
| Quote: | | 5. emerge -uDNX world |
Ich denke, dies sollte sich relativ leicht über Checksummen realisieren lassen. Für die Ebuilds und Files gibt es ja bereits eine Manifest Datei. Noch eine Manifest-Datei für die Eclass'es und diese beim Installieren mit unter /var/db/pkg sichern, und schon kann man vergleichen.
Für die Realisierung von 4. sehe ich auch nur die Möglichkeit über diff:
-Prüfe Checksummen, falls unterschiedlich
-awk $ebuild_im_portagetree
-awk $ebuild_in_vdb
-diff
-wenn diff was liefert, neu emergen
Natürlich geht es auf Performance. Man muss es jedoch nicht immer nutzen. Bisher hatte ich 1-2x pro Jahr ein emerge -e world laufen lassen, damit Änderungen nachgezogen werden. Daher würde ich es begrüßen eine Möglichkeit zu haben bei etwas längeren Check-Phase auf ein "emerge -e world" verzichten zu können und somit das System öffter auf dem aktuellsten Stand zu haben. |
|
| Back to top |
|
|
Necoro
Veteran
Joined: 18 Dec 2005
Posts: 1912
Location: Germany
|
| Posted: Tue Apr 29, 2008 9:48 am Post subject: |
|
|
| bell wrote: | | Bisher hatte ich 1-2x pro Jahr ein emerge -e world laufen lassen, damit Änderungen nachgezogen werden. |
Sinn? Welchen Sinn hat dieses Vorgehen? - Bzw was versprichst du dir davon?
_________________
Inter Deum Et Diabolum Semper Musica Est. |
|
| Back to top |
|
|
bell
Guru
Joined: 27 Nov 2007
Posts: 514
|
| Posted: Tue Apr 29, 2008 10:36 am Post subject: |
|
|
Sinn:
Ich hatte vor ein Paar Jahren mal das Cruft-Script http://de.gentoo-wiki.com/Das_Cruft_Script ausprobiert, etwas destruktiver gelöscht und anschließend "emerge -e world" laufen lassen. Zu meiner Überraschung erschienen dann Menü-Einträge im Gnome-Menü, für die ich vorher selbst Starter anlegen musste. Viele Programme hatten verbesserte Konfigurationen mitgebracht, auf die ich dann beim etc-update gestoßen bin. Teilweise wurde auch mehr Dokumentation installiert.
Ich war verwundert, bin der Sache jedoch damals nicht nachgegangen. Aber seit dem mache ich je nach Laune und meist zusammen mit GCC oder Glibc Update 1-2x pro Jahr Cruft-Remove und emerge -e world. Bei den letzten paar mal hatte das Cruft-Script kaum noch etwas geliefert. Portage ist anscheinend sehr robust geworden. Daher begrüße ich auch, dass "emerge -e world" für meinen Fall nicht mehr notwendig wäre. |
|
| Back to top |
|
|
Carlo
Developer
Joined: 12 Aug 2002
Posts: 3356
|
| Posted: Tue Apr 29, 2008 2:32 pm Post subject: |
|
|
| Genone wrote: | | Stimmt so pauschal nicht, das ist immer eine Frage der Verhältnismäßigkeit. |
Weswegen ich meiner Meinung nach legitime Gegenbeispiele aufgeführt habe. Der entsprechende Absatz in der Ebuild Policy ist mir zu vage gefaßt, da er als Freifahrtschein aufgefaßt werden kann, über Probleme hinwegzusehen und auch nicht zwischen im Test befindlichen und stabil markierten Ebuilds unterscheidet. Lieber eine Revision zu viel, als ein evtl. unterschätztes Problem die Nutzerschaft ausbaden zu lassen.
Zu meiner Aussage bezüglich Verstößen: Das (nicht nur) mir zuletzt sauer aufgestoßene Beispiel sind die Änderungen an gettext-0.17.ebuild, nachdem es stabil markiert wurde.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs. |
|
| Back to top |
|
|
toralf
Developer
Joined: 01 Feb 2004
Posts: 3942
Location: Hamburg
|
| Posted: Wed Apr 30, 2008 9:12 am Post subject: |
|
|
Hi Carlo, Dein Script kannst Du noch schneller machen, wenn Du in der cleanup - Funktion die vielen grep - Befehle durch einen einzigen ersetzt : | Code: | #!/bin/sh
#set -x
I=/tmp/ebuild.installed
C=/tmp/ebuild.portage
cleanup () {
grep -v $1 \
-e "^$" \
-e '#' \
-e 'KEYWORDS=' \
-e 'HOMEPAGE=' \
-e 'LICENSE=' \
-e 'SRC_URI=' \
-e 'eerror' \
-e 'einfo' \
-e 'ewarn' \
-e 'elog'
}
cd /var/db/pkg/ || exit 1
find . -mindepth 3 -type f -name '*.ebuild' |\
sort |\
while read FILE
do
EBUILD_INSTALLED=$(basename $FILE)
PACKAGE=$(echo $EBUILD_INSTALLED | cut -f1 -d '.')
CATEGORIE=$(echo $FILE | cut -f2 -d'/')
EBUILD_PORTAGE=$(ls /usr/portage/$CATEGORIE/$(echo $PACKAGE | cut -f1 -d'-')*/$EBUILD_INSTALLED 2>/dev/null)
[[ -f $EBUILD_PORTAGE ]] || continue
cleanup $FILE > $I
cleanup $EBUILD_PORTAGE > $C
DIFF=$(diff $I $C 2>/dev/null)
if [[ $? -eq 1 ]]; then
echo -e "$CATEGORIE/$(basename $(dirname $EBUILD_PORTAGE))\t$EBUILD_INSTALLED"
[[ "$1" = "-v" ]] && echo -e "$DIFF\n"
fi
rm $I $C
done
|
In wieweit man die Lesbarkeit von "dirname" und "basename" zugunsten der schnelleren bash - builtins aufgibt, ist hier eher Geschmackssache. |
|
| Back to top |
|
|
bell
Guru
Joined: 27 Nov 2007
Posts: 514
|
| Posted: Wed Apr 30, 2008 10:38 am Post subject: |
|
|
Vielen Dank toralf,
bis auf -e '#' bin ich mit der Beschleunigung einverstanden. Es gibt ja auch Kommentare neben den Befehlen. Also:
| Code: |
cleanup () {
sed 's/#.*//g' $1 | \
grep -v $1 \
-e "^$" \
-e 'KEYWORDS=' \
-e 'HOMEPAGE=' \
-e 'LICENSE=' \
-e 'SRC_URI=' \
-e 'eerror' \
-e 'einfo' \
-e 'ewarn' \
-e 'elog'
}
|
Eigentlich dachte ich anfangs an awk, python oder perl regular expressions, da man damit viel präziser definieren kann, was ignoriert werden soll. Da ich aber da noch nicht so ganz fit bin, habe ich erstmal sed und grep genommen. |
|
| Back to top |
|
|
toralf
Developer
Joined: 01 Feb 2004
Posts: 3942
Location: Hamburg
|
| Posted: Wed Apr 30, 2008 10:52 am Post subject: |
|
|
| bell wrote: | | bis auf -e '#' bin ich mit der Beschleunigung einverstanden. |
Stimmt, dann vielleicht "-e '^#'" ?
| bell wrote: | | Eigentlich dachte ich anfangs an awk, python oder perl regular expressions, da man damit viel präziser definieren kann, was ignoriert werden soll |
Stimmt. Was man letztendlich bevorzugt, ist meiner Erfahrung nach eher Geschmackssache, ich bevorzuge mittlerweile Lesbarkeit gegenüber Schnelligkeit. |
|
| Back to top |
|
|
bell
Guru
Joined: 27 Nov 2007
Posts: 514
|
| Posted: Wed Apr 30, 2008 11:38 am Post subject: |
|
|
Ich bevorzuge auch Lesbarkeit. Jedoch stößt man mit sed und grep schnell an die Grenze, dass kein Filter auf mehrere Zeilen gesetzt werden kann, z.B. HOMEPAGE= kann mehrere Einträge haben, die in mehreren Zeilen stehen. Diese werden dann mit grep nicht ausgefiltert.
Aber erstmal wieder zurück zur Thematik an sich.
Ich muss @mv zustimmen. Mit generischer Auswertung kriegt mann nur Änderungen an den bereits installierten Pakete mit. Für das Erkennen der anderen Änderungen sollte eine weitere Versionsnummer hinzukommen. Das hätte auch den Vorteil, dass man nur einen bestimmten Stand maskieren kann, und wenn das Ebuild aktualisiert wird, schlägt emerge -u wieder ein Update vor.
Für die zusätzliche Versionsnummer würde sich die CVS-Revisionsnummer anbieten. Ich denke, dass es machbar wäre diese beim ausschecken aus dem CVS auf den rsync-Server automatisch dranzuhängen. Die mittlere Stufe (siehe Vorschlag von @mv) ergibt aus meiner Sicht keinen Sinn, da diese der bereits jetzt vorhandenen Revisionsnummer keinen Vorteil bietet. Diese wird von der selben Person vergeben und hat daher konzeptbedingt die selben Schwachstellen.
Auf eine generische Analyse können wir hier jedoch nicht verzichten, da nur über die Revisionsnummern man die Änderungen an files und eclasses nicht direkt mitkriegt. Die Endgültige Lösung müsste also Zusätzliche Revisionsnummer und Ebuild-Analyse+Vergleich kombiniert beinhalten.
Gestern ist mir noch eine Möglichkeit eingefallen, die normalerweise den nicht-Technikern einfällt, wie man ein Problem rein technisch lösen möchte:
Wäre es möglich, dass sobald ein Ebuild mit Stable-ARCH markiert wird, alle Devs, die zu diesem ARCH-Team gehören, keine Änderungen mehr für diese Date einchecken können? Also Ebuild-Update ~x86 -> x86 : x86-Developer können die Datei nicht mehr ändern und müssen eine neue ~x86 Revision beginnen. |
|
| Back to top |
|
|
Polynomial-C
Retired Dev
Joined: 01 Jun 2003
Posts: 1432
Location: Germany
|
| Posted: Wed Apr 30, 2008 12:13 pm Post subject: |
|
|
Naja, sowas ähnliches gibt es ja bereits, allerdings im header von jedem ebuild. Dort werden die ebuilds ebenfalls als Revisionen geführt:
| Code: | --- /var/db/pkg/app-shells/bash-3.2_p33/bash-3.2_p33.ebuild 2008-01-12 13:53:04.000000000 +0100
+++ /usr/portage/app-shells/bash/bash-3.2_p33.ebuild 2008-03-01 22:05:39.000000000 +0100
@@ -1,6 +1,6 @@
# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/app-shells/bash/bash-3.2_p33.ebuild,v 1.4 2008/01/02 17:51:15 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/app-shells/bash/bash-3.2_p33.ebuild,v 1.5 2008/03/01 20:38:04 vapier Exp $
inherit eutils flag-o-matic toolchain-funcs multilib
@@ -68,6 +68,7 @@
epatch "${FILESDIR}"/${PN}-3.1-gentoo.patch
epatch "${FILESDIR}"/${PN}-3.2-loadables.patch
epatch "${FILESDIR}"/${PN}-3.2-parallel-build.patch #189671
+ epatch "${FILESDIR}"/${PN}-3.2-ldflags-for-build.patch #211947
# Fix process substitution on BSD.
epatch "${FILESDIR}"/${PN}-3.2-process-subst.patch |
_________________
The manual said "Requires Windows10 or better" so I installed GNU/Linux...
my portage overlay
Need a stage1 tarball? (Unofficial builds) |
|
| Back to top |
|
|
bell
Guru
Joined: 27 Nov 2007
Posts: 514
|
| Posted: Sun May 18, 2008 8:09 pm Post subject: |
|
|
Wegen Nachfrage (zwar gering, jedoch vorhanden) habe ich bei gentooforums.de unter Tipps&Tricks ein Thread aufgemacht, wo ich immer die aktuellste Version des Skriptes hinterlassen werde. Als Ausgangsbasis habe ich die Version von @toralf genommen. Danke für die Optimierung. Ein Paar Änderugnen habe ich da schon drin.
Ich denke, für den Anfang muss es nicht sofort in emerge rein. Eventuell wird das Skript irgendwann gut genug for app-portage/portage-utils oder app-portage/gentoolkit sein. Zur Zeit ist es noch ein Prototyp. Den Thread findet Ihr unter http://www.gentooforum.de/artikel/15431/system-aktuell-halten-f-r-versionsjunkies.html. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German) 
