[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [buildd-tools-devel] apt-get option to keep dummy packages



On Thursday 18 November 2010 14:04:19 David Kalnischkies wrote:
> On Thu, Nov 18, 2010 at 19:30, Andres Mejia <mcitadel@gmail.com> wrote:
> > On Thursday 18 November 2010 11:58:24 David Kalnischkies wrote:
> >> On Thu, Nov 18, 2010 at 15:43, Roger Leigh <rleigh@codelibre.net> wrote:
> >> > On Thu, Nov 18, 2010 at 09:14:48AM -0500, Andres Mejia wrote:
> >> >> On Thursday 18 November 2010 05:29:22 David Kalnischkies wrote:
> >> >> > On Wed, Nov 17, 2010 at 19:55, Andres Mejia <mcitadel@gmail.com> 
wrote:
> >> > I'd just like to add that, while we are currently going with the
> >> > "dummy dependency package" approach to get apt-get to install/remove
> >> > depends/conflicts, we're open to alternative approaches.
> >> > 
> >> > The actual requirement is to
> >> > - install a list of build-depends
> >> > - remove a list of build-conflicts
> >> > - ideally in a single operation.
> >> > This isn't just a list of packages; it also includes versioned
> >> > dependencies and alternative dependencies, so what we want to
> >> > provide to apt-get is basically what you'd have in a Depends:
> >> > and Conflicts: field and get it to resolve them.  Installing a
> >> > dummy package is the current approach to getting this information
> >> > to apt-get, but there may be better ways.  Getting apt-get to
> >> > install the local package and resolve the deps in a single operation,
> >> > rather than involving dpkg would be an option, but setting up a local
> >> > repo is not to easy, considering the need for everything to be signed,
> >> > but it's something to consider if a feasible approach.
> >> 
> >> What i could imagine is an apt-get build-dep ./apt-0.8.9/debian/control
> >> Shouldn't be incredible hard implement as TagFile-Parsers and co
> >> are available and the Sources entries are parsed as well on the fly…
> >> (build-dep itself needs to be seriously improved through)
> >> 
> >> > Another requirement not mentioned above that apt and aptitude both
> >> > currently fail on is the need to resolve alternative and virtual
> >> > dependencies /predictably/.  That is, we could like it to consider
> >> > the alternatives in a left-to-right order, picking the first that
> >> > can be satisfied, rather than treating all alternatives equally.
> >> > This is to ensure dependencies are resolved in a predictable manner
> >> > for each build on all architectures.  Virtual dependencies are a bit
> >> > harder; we currently just pick the first alphabetically--the rule it
> >> > uses isn't too important, so long as it's totally consistent.
> >> 
> >> Its one of the reasons APT (still) exists that people think it is simple
> >> and predictable - so i am somehow confused why you say the opposite.
> >> 
> >> In the event of A | B, APT always tries to install A before it tries B
> >> (with the only exception that B is already installed in required
> >> version). And regarding provides: #473247 - the bug exists because APT
> >> chooses the first provider it can find in the Packages files rather
> >> than doing something fancy (again, expect one provider is already
> >> installed). So, again, i would like to ask for an example again…
> > 
> > Here's an example that will exhibit this behavior.
> > Depends: libvtk5-dev | libopenal-dev
> > Conflicts: libavcodec52
> > 
> > This is just an example. I'm not aware of any package that has these
> > particular package relationships.
> > 
> > libvtk5-dev depends on libvtk5.4 which depends on libavcodec52.
> > libopenal-dev doesn't have any relationship with libavcodec52. I
> > expected apt to choose libopenal-dev to install. Instead, it removes the
> > dummy package.
> 
> Again a reason to ditch the --fix-broken mode in favor of an archive
> or at least for something more cleaner - if such a package is installed
> from an archive apt happily works out what you want/expect…
> (see attached apt testcase, drop into test/integration/ )
> 
> 
> I will have a look later why APT doesn't work it out in --fix-broken…
> 
> 
> Best regards
> 
> David Kalnischkies

Seems using 'apt-get build-dep dummy-archive' will fail too in similar manner 
as 'apt-get -f install'.

Attached is a patch to test 'Sources' entries and 'build-dep' command. Also 
included are the other files needed for testing.

-- 
Regards,
Andres Mejia
diff --git a/test/integration/framework b/test/integration/framework
index 2422f08..a75a242 100644
--- a/test/integration/framework
+++ b/test/integration/framework
@@ -110,6 +110,12 @@ setupenvironment() {
 	else
 		touch aptarchive/Packages
 	fi
+	local SOURCESSFILE=$(echo "$(basename $0)" | sed -e 's/^test-/Sources-/' -e 's/^skip-/Sources-/')
+	if [ -f "${TESTDIR}/${SOURCESSFILE}" ]; then
+		cp "${TESTDIR}/${SOURCESSFILE}" aptarchive/Sources
+	else
+		touch aptarchive/Sources
+	fi
 	cp $(find $TESTDIR -name '*.pub' -o -name '*.sec') keys/
 	ln -s ${TMPWORKINGDIRECTORY}/keys/joesixpack.pub rootdir/etc/apt/trusted.gpg.d/joesixpack.gpg
 	echo "Dir \"${TMPWORKINGDIRECTORY}/rootdir\";" > aptconfig.conf

Attachment: test-dummy
Description: application/shellscript

Package: dummy-archive
Priority: extra
Section: admin
Installed-Size: 5984
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: i386
Version: 0.invalid.0
Source: dummy-archive
Depends: libvtk5-dev | libopenal-dev
Conflicts: libavcodec52
Filename: pool/main/d/dummy/dummy_5.4.2-8_i386.deb
Size: 2280898
MD5sum: 569719746f7ec4b96209a6152af20c00
Description: some dummy package

Package: build-essential
Priority: optional
Section: devel
Installed-Size: 48
Maintainer: Matthias Klose <doko@debian.org>
Architecture: i386
Version: 11.5
Filename: pool/main/b/build-essential/build-essential_11.5_amd64.deb
Size: 7178
MD5sum: 1a28a6d7718debc321169b501f5ffe9d
Description: Informational list of build-essential packages
Build-Essential: yes

Package: libvtk5-dev
Priority: optional
Section: libdevel
Installed-Size: 13812
Maintainer: A. Maitland Bottoms <bottoms@debian.org>
Architecture: i386
Source: vtk
Version: 5.4.2-8
Depends: libvtk5.4 (= 5.4.2-8)
Filename: pool/main/v/vtk/libvtk5-dev_5.4.2-8_i386.deb
Size: 2280898
MD5sum: 569719746f7ec4b96209a6152af20c00
Description: VTK header files for building C++ code

Package: libvtk5.4
Priority: optional
Section: libs
Installed-Size: 39372
Maintainer: A. Maitland Bottoms <bottoms@debian.org>
Architecture: i386
Source: vtk
Version: 5.4.2-8
Depends: libavcodec52 (>= 4:0.5.1-1)
Filename: pool/main/v/vtk/libvtk5.4_5.4.2-8_i386.deb
Size: 13070848
MD5sum: 3ba7abc3d58ec44e35ae71879406563d
Description: Visualization Toolkit - A high level 3D visualization library

Package: libopenal-dev
Priority: optional
Section: libdevel
Installed-Size: 140
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Architecture: i386
Source: openal-soft
Version: 1:1.12.854-2
Filename: pool/main/o/openal-soft/libopenal-dev_1.12.854-2_i386.deb
Size: 21014
MD5sum: e0bda4fbf5a3d38ef510a23a1642587f
Description-de: Software-Implementierung der OpenAL-API (Entwicklungsdateien)

Package: libavcodec52
Priority: optional
Section: libs
Installed-Size: 10772
Maintainer: Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
Architecture: i386
Source: ffmpeg
Version: 4:0.5.2-6
Filename: pool/main/f/ffmpeg/libavcodec52_0.5.2-6_i386.deb
Size: 4001600
MD5sum: a50aae4c8e8b9dd29612407e61bedc22
Description-de: Ffmpeg-Codec-Bibliothek
Package: dummy-archive
Binary: dummy-archive
Version: 0.invalid.0
Priority: extra
Section: misc
Maintainer: Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>
Build-Depends: libvtk5-dev | libopenal-dev
Build-Conflicts: libavcodec52
Architecture: any
Standards-Version: 3.9.1
Format: 1.0
Package: dummy-dpkg
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 5984
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: i386
Version: 0.8.8
Depends: libvtk5-dev | libopenal-dev
Conflicts: libavcodec52
Description: some dummy package

Reply to: