Am Sonntag 14 Juni 2009 10:28:00 schrieb Allan McRae:

I'm not really a fan of this as it fills the PKGINFO file and pacman DB with info that is really not needed. At the moment you can simply grep the ABS tree to check for depends/makedepends.

I am not sure myselfM; that's why I brought it up here. Of course this information is completely useless for user and just wastes space. But here I wonder if such a few bytes more really matter. On the other side this is really usefull if you write tools for packagers. The advantage of retreiving the information from the package/db over grepping the ABS tree is: * it does not depend on Arch * there is no need to check out the complete tree * tools can use a unified way to access all kinds of deps So, only a very limited group will benefit from this and if all others will have disadvantages we should probably drop the idea. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de

Pierre Schmitz wrote:

Am Sonntag 14 Juni 2009 10:28:00 schrieb Allan McRae:

...

I'm not really a fan of this as it fills the PKGINFO file and pacman DB with info that is really not needed. At the moment you can simply grep the ABS tree to check for depends/makedepends.

I am not sure myselfM; that's why I brought it up here.

Of course this information is completely useless for user and just wastes space. But here I wonder if such a few bytes more really matter.

On the other side this is really usefull if you write tools for packagers. The advantage of retreiving the information from the package/db over grepping the ABS tree is: * it does not depend on Arch * there is no need to check out the complete tree * tools can use a unified way to access all kinds of deps

So, only a very limited group will benefit from this and if all others will have disadvantages we should probably drop the idea.

Seeing the numbers you provided in the other email and the advantages indicated here, I am now fine with including this in the pacman-db. It would be quite useful for my rebuild order script which currently misses makedepends.... Allan

On Mon, Jun 15, 2009 at 8:30 PM, Allan McRae wrote:

...

Pierre Schmitz wrote:

...

Am Sonntag 14 Juni 2009 10:28:00 schrieb Allan McRae:

...

I'm not really a fan of this as it fills the PKGINFO file and pacman DB with info that is really not needed.  At the moment you can simply grep the ABS tree to check for depends/makedepends.

I am not sure myselfM; that's why I brought it up here.

Of course this information is completely useless for user and just wastes space. But here I wonder if such a few bytes more really matter.

On the other side this is really usefull if you write tools for packagers. The advantage of retreiving the information from the package/db over grepping the ABS tree is: * it does not depend on Arch * there is no need to check out the complete tree * tools can use a unified way to access all kinds of deps

So, only a very limited group will benefit from this and if all others will have disadvantages we should probably drop the idea.

Seeing the numbers you provided in the other email and the advantages indicated here, I am now fine with including this in the pacman-db.  It would be quite useful for my rebuild order script which currently misses makedepends....

To further rationalize, it also helps answer the question "How was this package built?"

Would this let you rebuild a package from the database alone? Is the other info from the PKGBUILD along with the local source files included somewhere? Can someone give some concrete examples of how this could be useful in the absence of the other packaging information and who would be likely to use this?

...

Can someone give some concrete examples of how this could be useful in the absence of the other packaging information and who would be likely to use this?

Maybe "built" was too strong of a word... what I was trying to say: You can see, somewhat, what was enabled at build time, to see what things support, in some cases.

Sorry if it's a noobish question, but can you give some example of when that info might be useful? I can't think of anything practical at the moment that would rely on knowing the makedepends but not the rest of it, at least not in the pacman database.

I'm not thinking in terms of scripting and the like, I'm thinking in terms of information. Like... "oh this needed mysql-libs to build, so maybe it has mysql support"

I don't think it would be all that useful in that case. You wouldn't query the database to find all packages that might have mysql support. If you were interested in that you would probably have a few apps in mind the features of which you would like to compare. If you're trying to determine if an app supports what you need, you would check the website or the manpage, wouldn't you? As pacman would have no direct use for the makedepends, I don't think it would be worth adding them to the database. To achieve what you've just mentioned, adding some sort of tag support would make more sense and be far more useful. I don't actually support that idea though, but listing the makedepends as currently suggested would effectively create a glorified tag system with restricted input. Perhaps another solution would be to convert the abs tree into a third database alongside sync and local. It would be completely optional as abs currently is but once installed pacman (or another binary built for that purpose) would be able to query it for such things as makedepends in a format similar to the current sync and local queries. It would also make it possible to seemlessly build files from source with dependency resolution. Maintaining the database itself is not an issue as the abs tree already exists. Distribution would require archiving each package's PKGBUILD and local source files for distribution on the mirrors similar to the way binary packages currently are (which would take a load of the current abs server and be far smaller than any of the binary repos). The database archive itself would contain files with information extracted from PKGBUILD in the same format followed by desc and depends files in the sync and local databases (including information such as makedepends, optdepends, sourceURLs, etc).

Pierre Schmitz wrote:

On Tuesday 16 June 2009 22:38:52 Aaron Griffin wrote:

...

I'm not thinking in terms of scripting and the like, I'm thinking in terms of information. Like... "oh this needed mysql-libs to build, so maybe it has mysql support"

Imho the other way round is more usefull: * What packages depend on e.g. mysql at build time? ** Maybe I want to move/remove it. Quite often we want to know if a package can safely be removed. ** Maybe I have a .so bump and want to know what might break in future rebuilds ** Maybe I want to rebuild those that are statically linked and rebuild them (e.g. bug fixes, security etc.) * With a complete dependency graph I can automaticaly check for unused libs etc. (think about repo cleanup) * Make a repo check/validation easier. E.g. cross repo dependencies, ...

Note that all of these are easily done already... either grepping through the ABS tree or using the rebuild scripts that I posted to the arch-dev-public list. The only advantage I see of this is that instead of grepping through the ABS tree (which may not be implemented for all users of pacman...), you can grep through the pacman sync db. I see no reason for adding this to the -S/Qi output as when it is important, it will be displayed in optdepends. Allan

On Wednesday 17 June 2009 06:39:49 Xyne wrote:

Considering that only a very few people will actually use this, is it really worth adding to the database of all users if it's already possible to do this with the abs tree? Won't most people who would use this already have the abs tree installed?

Sure, only few people would benefit from these changes. But it will make tools easier and queries are more unified. But let's not forget that the only downside of this extremely simple patch is adding a few bytes to the db/package bytes. (What was it? ~1,6KB for all repos together including testing and community) -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de

On Wed, Jun 17, 2009 at 12:08 AM, Allan McRae wrote:

Xyne wrote:

...

...

Note that all of these are easily done already...  either grepping through the ABS tree or using the rebuild scripts that I posted to the arch-dev-public list.

The only advantage I see of this is that instead of grepping through the ABS tree (which may not be implemented for all users of pacman...), you can grep through the pacman sync db.  I see no reason for adding this to the -S/Qi output as when it is important, it will be displayed in optdepends.

Considering that only a very few people will actually use this, is it really worth adding to the database of all users if it's already possible to do this with the abs tree? Won't most people who would use this already have the abs tree installed?

Do not think of pacman as Arch specific.  Can you currently get this info easily for KDEmod?  How about any of the other distros using pacman?

As a rather wild aside here... what would be the downside of sticking the entire PKGBUILD in the pacman DB? How much size would that add?

On Wed, Jun 17, 2009 at 12:34 AM, Pierre Schmitz wrote:

On Wednesday 17 June 2009 07:27:11 Aaron Griffin wrote:

...

As a rather wild aside here... what would be the downside of sticking the entire PKGBUILD in the pacman DB? How much size would that add?

Wont make that much sense (as it is not easily parsable and without patches etc. quite useless) However for community/  core/  extra/  kde-unstable/ local/  testing/ it is (gzip compressed) 1,1M

But you're just kidding, right?

Not exactly - I'm half serious. I mean, a) it'd give us all the information needed to build the package, b) it'd allow these scripts to work without an ABS tree. I'm not saying pacman would _use_ it, I just think it'd be kinda neat.