libapt-pkg-dev should give you more or less what you need, I guess...

But it's written in C++, it looks cool, but it's just very difficult to use from a C program.

libept provides a C++ interface to apt.  If you must use C, there's the underlying libapt-pkg.

>If you must use C, there's the underlying libapt-pkg.

This is c++ still, no?

Yeah, oops.  C++ it is.

I suppose that “apt-cache search 'regex query' --full” might be enough to meet your second requirement.

yes, that does the trick, thanks.

apt is written in C++ - there are no C bindings. C++ and Python is all that's out there at the minute AFAIR.

There's AptPkg for Perl.

have you considered Smart for the backend?

Try using Smart Package Manager for the backend. This way you can acheive a few things:

1) probably you can still go ahead and do it in c or do it in python (smart is written in python)
2) You don't have to reinvent the wheel (smart can handle many package systems already (apt, rpm, urpmi etc) and can usually do it in a more efficient way - arguably a better depsolver than apt and yum)
3) Smart is available for lots of Linux flavours
4) You only have to compile in support for one package manager so packagekit works with everything from the get go (see point 2).

It sort of meets many of the requirements on the wiki page.

Re: have you considered Smart for the backend?

>Try using Smart Package Manager for the backend

Sure. I see no reason why we couldn't have a smart backend, but we also have to support systems without smart for obvious reasons.

My point is that if you support smart (perhaps instead of the dummy backend) then you will automatically support most systems as smart works with many native packaging backends already. Probably reduce your development time in half.

Presuming they have smart installed.

Everyone has smart installed! No? :)

yum

There's obviously no c binding for yum since it is all in python but if you want an output of a search for power tab delimited here you go:
http://skvidal.fedorapeople.org/search-tab-packagekit.py

It returns:
namesummarydescription

there's nothing in the rpm metadata which provides a 'proper name' for the package.

If you want different data, let me know.

Re: yum

That's really appreciated, many thanks.

Red Carpet

Take a look at Red Carpet, which is a backend-neutral packaging system that I worked on for a few years. Unfortunately most of it got swallowed up by Zenworks when Novell bought Ximian and retargetted more toward an enterprise model. However, all of the client code is open source and they're all still in GNOME SVN. One of the other developers, James Willcox (snorp) has taken up development of it again on the "yummy" branch: http://www.snorp.net/log/2007/04/26/return-of-the-carpet/

Anyway, the components in GNOME SVN are:

* libredcarpet: A general-purpose packaging library. It provides a package management abstraction (packman) which supports both RPM 3, RPM 4 and dpkg; a partial-graph dependency resolution system which is still today better than any other I've used; the ability to lock packages, either at a certain version or to prevent them from being installed altogether, with dep resolver support; support for Red Carpet-specific metadata, apt repos, and now the new yum repodata format; some basic distro detection; a test suite for the dependency resolver; language bindings into Python and Mono. The APIs are very GNOME-like and some are GObject based.

* rcd: The Red Carpet Daemon. Originally the idea was to expose to desktop applications all the packaging functionality, but it never happened and isn't all that interesting. Over time it became more focused on enterprisey, centralized deployment. Snorp's recent work has made a daemon more sensible for general use by going to sleep whenever not in use and greatly shrinking its memory footprint. RCD provides packaging history; smart package set functionality; search for packages by name, summary, description. Communication with clients is done through XML-RPC either through Unix domain sockets (for local clients) or HTTP (for remote clients)... a reimplementation or large refactoring would suggest a move to D-Bus instead. It is written in C.

* rug: An extremely powerful command-line client to rcd written in Python. I've still never used a command-line client as nice as the original rug (including the C# rewrite which talked with Zenworks). There are a bunch of nice touches like being able to install and remove packages at the same time; easily browsing and searching package history; great search features; the ability to abbreviate or acronym just about anything; etc.

* red-carpet: A GUI to rcd, also written in Python. The UI is pretty nice, but still aimed at people familiar with packaging systems -- ie, system administrators. What you probably want are a couple of different user interfaces, including an update one somewhat closer to the original Ximian Updater (http://i.iinfo.cz/r/photos/helix-update.jpg).

A lot of these things were solved by Red Carpet back in the day. Part of the reasons why I feel it never took off as a cross-distribution update system include:

* Most companies (Red Hat and Ximian included) saw the update system as a primary means to make money (with Red Hat Network and Red Carpet Enterprise, respectively) and were unwilling to surrender any control over this pipeline to someone else.

* People didn't like the idea of a packaging daemon running on their system, which makes sense -- it only really makes sense in the context of a centralized deployment scheme.

We originally started Red Carpet in late 2000, and it went through basically a rewrite (to the rcd system) in 2002 or 2003, so there are some things it doesn't do very well: It doesn't handle multiple architectures as well as it should -- nobody had 64-bit and 32-bit mixed environments like x86-64 then; the dpkg backend has almost certainly bitrotted; the RPM backend is *incredibly* dynamic because the RPM library API used to change *with every micro version* and so there are some amazing hacks in there to work with everything from RPM 3.x to more recent 4.x releases -- it would be greatly simplified if a lot of that cruft were removed; obviously XML-RPC isn't a great choice for a desktop system these days; etc. etc.

But if you're really interested in taking a stab at the packaging problems, please please please take a look at the stuff that has come before. We did a lot of good work there. :)

Thanks,
Joe Shaw

Re: Red Carpet

> ...unfortunately most of it got swallowed up by Zenworks when Novell bought Ximian and retargetted more toward an enterprise model.

Yes, a real shame.

>...snorp has taken up development of it again on the "yummy" branch...

Cool, I'll take a look, thanks for the link.

>...a partial-graph dependency resolution system...

Ohh, that's something I want to avoid. That's when things get very complicated very quickly.

>...The APIs are very GNOME-like and some are GObject based...

Cool, I'll take a look. With dbus a client side library is sort-of moot but I get your points.

>...Over time it became more focused on enterprisey, centralized deployment...

Which was a shame IMO.

>...going to sleep whenever not in use and greatly shrinking its memory footprint...

Cool.

>...a reimplementation or large refactoring would suggest a move to D-Bus instead. It is written in C.

Sounds really good. I'll check out the source and take a look.

>...I've still never used a command-line client as nice as the original rug...

Sure. It's got to beat what I'm using at the moment, pk-console --mode=search --value=evince --verbose --async :-)

>...but still aimed at people familiar with packaging systems -- ie, system administrators...

Yes, a "power" tool.

>...What you probably want are a couple of different user interfaces...

Yes, as different actions should have different tools. I agree with you there.

>...saw the update system as a primary means to make money (with Red Hat Network and Red Carpet Enterprise, respectively) and were unwilling to surrender any control over this pipeline to someone else....

Yes, this is where it gets political very quickly. I'm intending to work around that and not touch this at all for now.

>...a packaging daemon running on their system...

Well, just for updates and installing stuff we can now use dbus system activation, although that's only covering some use cases.

>...nobody had 64-bit and 32-bit mixed environments like x86-64...

Welcome to a world of pain. Seriously, I'm just leaving this to apt and yum to figure out.

>...please please please take a look at the stuff that has come before. We did a lot of good work there.

Yes, I totally agree. Let me look at some source and then I can better get an idea of what retcarpet did right, and what it did wrong. I still like the idea of a simple abstraction for packaging, but maybe not on the scale of red carpet with dep resolution and that sort of thing.

I'm getting a mailing list set up for this sort of stuff, I'll give you a yell when that's done. Thanks for the great blog comment!

URPMI backend

Mandriva is using a Perl based tool for its package management ( URPMI ). Do you plan eventually in the future to have backends for urpmi and/or are you willing to accept patches from Mandriva dev ?
http://www1.mandrivalinux.com/cooker/urpmi.html
http://cvs.mandriva.com/cgi-bin/viewvc.cgi/soft/perl-URPM/
http://search.cpan.org/dist/urpmi/

Re: URPMI backend

Sure. That's the point of PackageKit. If it doesn't have a urpmi backend then that's a bug in my book.

Thanks

i need c++ teacher. Thanks you.

SEO
Knight Online
Balıkçılık