[packagekit] PackageKit and source packages?

[Anders F Björklund]

Richard Hughes wrote:

>> Shouldn't the arch be changed too, to download the source
>> rather than a pre-compiled version if one is available ?
> 
> Yes, sorry, that was my mistake. It should have been something like
> Package(available, sane;0.3.0;src;fedora-source, Scanner software)

Okay.

>> When you install, it tries to download a binary .tbz if one
>> is available otherwise it falls back to building from source.
> 
> Makes sense.

Theoretically the "portage" backend works the same, just that
there is no bother to check for .tbz2 since nobody builds them.

emerge --usepkg --getbinpkg *
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=3#doc_chap4


>>> ->   DownloadPackage(sane;0.3.0;i396;fedora-source, "/tmp")
>>> <-   Package(downloading, sane;0.3.0;i396;fedora-source, Scanner software)
>>> <-   Files(sane;0.3.0;i396;fedora-source, "/tmp/sane-0.3.0.i396.srpm")
>>> <-   Finished()
>> 
>> That should probably be more like .src.rpm than .i386.srpm ?
>> Relating to the arch question above, shouldn't it be "src".
> 
> Yup, sorry.

So more like:
Files(sane;0.3.0;src;fedora-source, "/tmp/sane-0.3.0.src.rpm")

>>> or, if we just want the files list of the source package:
>>> 
>>> ->   GetFiles(sane;0.3.0;i396;fedora-source, "/tmp")
>>> <-   Files(sane;0.3.0;i396;fedora-source, "/usr/share/sane/README")
>>> <-   Finished()
>> 
>> So when you query a source package, you get the files that
>> would be installed - e.g. build and peek at $RPM_BUILD_ROOT ?
> 
> Yup. It's easy for a src.rpm as the file list is in the metadata, but
> for building-as-src distros, it might just be sane to emit
> NO_SUPPORTED.

The file list in the repodata is for the *.src.rpm (e.g. *.spec)
Otherwise you look at the result for the binary .rpm's instead...

>> It seemed more likely that it would consist of files like
>> *.spec and *.tar.gz (or similar, like *.patch *_orig.tar.gz)
> 
> I think that's also a sane thing to do.
> 
>> Would PackageKit also support for BuildDepends and BuildPackage ?
>> Or is this more of an informational query, like a metadata field ?
> 
> Yup, I see it more of an informational thing than an interface for
> building. That would get complex really quickly in my opinion.

Makes sense...

Guess the backends without actual source packages would have to
fake a source architecture package, when doing the "GetSource" ?

And then later wing it, when going to download the src "package",
to download all the files that make up the source for the package:

e.g. DownloadPackage(packagekit;0.6.11-2ubuntu3;src;oneiric, "/tmp") ->
http://archive.ubuntu.com/ubuntu/pool/main/p/packagekit/packagekit_0.6.11-2ubuntu3.dsc
http://archive.ubuntu.com/ubuntu/pool/main/p/packagekit/packagekit_0.6.11.orig.tar.gz
http://archive.ubuntu.com/ubuntu/pool/main/p/packagekit/packagekit_0.6.11-2ubuntu3.debian.tar.gz

i.e. os.path.dirname(ver.fetch_source(dest, progress, unpack=False))
instead of regular ver.fetch_binary(dest, progress)

And you would find your *.dsc in that directory path,
just as you find your *.spec in the source rpm archive...

Possibly create a subdirectory for the "package" first,
but that's trivial enough (passed in as the "destdir").

Files(packagekit;0.6.11-2ubuntu3;src;oneiric, "/tmp/packagekit_0.6.11-2ubuntu3/")

--anders


PS. Or similar in C++ rather than Python. (aptcc/apt)

    For ports, it would just pre-download distfiles
    - since the build script (Makefile) and patches
    are already available locally in the ports tree.