Testte kullanmak için sahte bir debian paketinin kurulumunu nasıl yaratırsınız?

Bu başlangıçta stackoverflow'a gönderildi ( https://stackoverflow.com/questions/47099045/how-do-you-create-a-dpkg-admin-directory ), ancak muhtemelen buraya ait

Daha önce yalnızca Debian merkezli dağıtımlar için .deb paketleri hazırladığım RPM tabanlı dağıtımları hedef alan bir paketim var.

Amaç, inşa ettiğiniz sistemden izole edilmiş bir kullanıcı alanından bir test kurulumunu simüle etmektir. Çok kullanıcılı olabilir ve yalnızca yazılımı oluşturmak için kök erişimi gerektirmek istemezsiniz. Testlerimizin çoğu zaten kurulum dizini yapısını simüle ediyor. Bu, inşa edilen paketleri kullanarak gerçek bir kurulumu simüle etmek için bir sonraki adım içindir.

RPM paketleri için aşağıdakileri kullanarak test kurulumları yapmayı başardım:

WSDIR=/where/I/want/my/tests/to/run
rpmdb --initdb --dbpath "$WSDIR"/rpmdb
rpm --relocate /opt="$WSDIR"/opt --dbpath $WSDIR/rpmdb -i <package>.rpm 

Debian dünyasında eşdeğeri şöyle bir şey:

dpkg --force-not-root --admindir=$WSDIR/dpkg --root=$WSDIR/install --install "$DEB" 

Ancak, rpmdb --initdbadımın eşdeğeri üzerinde sıkışıp kaldım .

Sadece arşivi kullanarak şu paketi açabileceğime dikkat edin:

dpkg-deb -x "$DEB" $WSDIR/install

Ancak gerçek bir paketin nasıl kurulduğuna daha yakın olmayı tercih ederim. Ayrıca bunun çalışacağını preinstallve postinstallsenaryoların olacağını sanmıyorum .

Benzer sorular deboostrapbir chrootortam oluşturmak için kullanmayı önerdi, ancak bu tamamen yeni bir kurulum oluşturuyor. Overkill olmasının yanı sıra otomatik bir test için çok yavaş. Bunu, gerçek test ortamlarında daha fazla test yapmadan önce, kurulum paketinin hızlı testlerinde kullanmak istiyorum.

Şimdiye kadar yaptığım deneyler:

(cd $WSDIR/dpkg && mkdir alternatives info parts triggers updates)
cp /var/lib/dpkg/status $WSDIR/dpkg/status

en iyi ihtimalle:

dpkg: error: unable to access dpkg status area: No such file or directory

yanlış olanı açıkça göstermez.

Peki yok bir dpkg Yönetici dizini oluşturmak?

Güncelleme 24/11/2017

Kovboy tarafından yaratılan bir ortamdan (kaputun altında deboostrap kullanan) dpkg dir kullanarak kopyalamayı veya / var / lib / dpkg'dan gerçek olanı kopyalamayı denedim, ancak yine de aynı hata mesajını alıyorum belki de (ve / ya da --admindir seçeneği) ne demek istediğimi tam olarak anlamadı.

Bunu not et:

sudo dpkg --force-not-root --root=$WSDIR/install  --admindir=/var/lib/dpkg --install "$DEB"

çalışır. Bu yüzden bu admind dir ile ilgisi var.

Ayrıca, "Nasıl bir dpkg yönetici dizini yaratıyorsunuz" sorusunu da ilginç bir soru olarak nitelendirdim, ancak sorunun cevabım mutlaka sorunumun çözümü değil.

Guillem Jover'a teşekkürler (bkz. Https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883700 ) ve dpkg kaynak kodunun üzerine bir miktar kazı çalışması. Şimdi bir çözümüm var:

mkdir fake
mkdir fake/install
mkdir -p fake/dpkg/info
mkdir -p fake/dpkg/updates
touch fake/dpkg/status
PATH=/sbin:/usr/sbin:$PATH fakeroot dpkg --force-script-chrootless --log=`pwd`/fake/dpkg.log --root=`pwd`/fake --instdir `pwd`/fake --admindir=`pwd`/fake/dpkg --install *.deb

Dikkat edilecek bazı noktalar:

• --force-not-rootyeterli değil. fakerootgerekli.

• ldconfigve start-stop-daemonyolda olmalı. (dolayısıyla PATH = / sbin: / usr / sbin: $ PATH)

• Günlük dosyası varsayılandan yeniden yerleştirilmeli /var/log/dpkg.log

• Argümanların sırası önemlidir. Kullanıldıysa --rootönce --instdirve olmalıdır --admindir.

• Admindir bir yükleme direk önek olması gerekiyordu.

• Paket, herhangi bir kurulum öncesi veya sonrası komut dosyası içeriyorsa (preinst, postinst), o zaman --force-script-chrootless gerekir, çünkü bu scriptler normalde sahte kök altında denemeye izin verilmediğinde çalışmaya izin veren chroot () aracılığıyla çalıştırılır.