proposal: a better than rpmfind solution for gentoo

Klavs · Guru Joined: 22 May 2002 Posts: 536 Location: Denmark

The other day, I didn't remember where I would get a certain file from, and for gentoo, I know of no way to find that out, except searching rpmfind and google, and see what comes up.

My proposal, is that we build a repository - 1 file, for each ebuild file, which should atleast contain every filename that this package can build (which will be dependant on use-settings). Instead of the developers doing the hard work, this could be added to portage - so people could contribute to gentoo - by just enabling uploads of file-lists (incl. ebuild versions, and use settings) to gentoo - that way we would quickly build up a central database, where people could search - just like rpmfind - and also it wouldn't be hard to let people download it just like a package to be able to search locally.

What do you guys think? am I the only guy who needs this - and don't like to rely on rpmfind and google, as they don't always find what I need.. f.ex. I can't find epm there.. (except for posts on gentoo-forum stating this particular file, but there are others which aren't easy to locate, I'm sure.).
_________________
Best regards,

Klavs Klavsen
Denmark

Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38.

klieber · Posted: Wed Jul 10, 2002 12:16 pm Post subject:

moving to Gentoo Suggestions.

--kurt
_________________
The problem with political jokes is that they get elected

klieber

Klavs · Guru Joined: 22 May 2002 Posts: 536 Location: Denmark

It doesn't work the way you describe for many files, I'm sorry to say.

I wanted that exact feature you meantion, but I tried:

amd root # emerge -s mcopy -p
[ Results for search key : mcopy ]
[ Applications found : 0 ]

even though mtools is even installed..

As you can see it does't work for that many files, of the ones in a package.
I often get some script, where they guy uses some obscure utility (especially for sgml stuff) and I have some times had my handsfull trying to figure out which package would get me that file..

This would work, if the system I suggest was implemented - as every file from any given package would be known to the system - which as you can see from my example with mcopy is NOT the case now.
_________________
Best regards,

Klavs Klavsen
Denmark

Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38.

klieber · Posted: Wed Jul 10, 2002 3:28 pm Post subject:

OK, I understand -- you mean for tools buried inside of other packages. That makes more sense and I agree that it's a real pain in the arse some times. (trying to figure out what package holds kmail and knode, for example)

You can sort of accomplish what you're trying to do with epm, but that only works for packages that are already installed on your system -- not much help when you're trying to install a specific tool...

I do, however, think that this responsibility falls upon the person who creates the ebuild to fulfill, perhaps by adding a new variable to each ebuild. (such as "PROVIDES" or something similar)

--kurt
_________________
The problem with political jokes is that they get elected

Klavs · Guru Joined: 22 May 2002 Posts: 536 Location: Denmark

I'm glad you like the idea, and see a need for it too :-)

I must however, disagree that that responsibility should be on the ebuild creator - cause that always means some won't do it - and besides I don't see why they should do extra, when it can be fully automated so no one, would have to do anything.. (that's the best way to solve things in my opinion).

Besides all the information to automate it, is already there in the local emerge db, so if we just merged the file-list from all, then we would know which file this ebuild CAN produce (this will be dependant on USE settings and that's why I wanted to merge the file-list's from a lot of people - so we can cover every possible USE setting).
_________________
Best regards,

Klavs Klavsen
Denmark

Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38.

klieber · Posted: Wed Jul 10, 2002 5:23 pm Post subject:

delta407 · Posted: Wed Jul 10, 2002 5:35 pm Post subject:

It wouldn't be too hard to do, you know. Portage can be told to automatically generate digest files (handy for ebuild maintainers), so why not set up an option that generates indexes of executables? ("find -perm +100" of the sandbox, for instance.) It would not be hard to make Portage search it, either.
_________________
I don't believe in witty sigs.

rac · Posted: Wed Jul 10, 2002 5:37 pm Post subject:

delta407 · Posted: Wed Jul 10, 2002 5:54 pm Post subject:

It wouldn't be that hard to implement, as long as ebuild maintainers use the sandbox (they had darn well better anyway). Heck, just "cd /var/tmp/portage/mypackage/version/; find > index" and you have all the files that said ebuild provides in index, ready to be copied to the respective /usr/portage/category/package/files/ directory.

Again, not too hard at all. The only problem would be search speed...
_________________
I don't believe in witty sigs.

klieber · Posted: Wed Jul 10, 2002 5:57 pm Post subject:

rac · Posted: Wed Jul 10, 2002 6:22 pm Post subject:

delta407 · Posted: Wed Jul 10, 2002 6:27 pm Post subject:

Hey, guys! You don't need dedicated hardware, and you don't need new tools. A "what provides this file" system can be made -- easily, I might add, compared to the other options -- by a mechanism similar to how digest files are made. I would guess the code necessary to come up with a file index would be under 50 lines of Python; it's just a matter of coding them and applying it to each ebuild. Again, we already have a digest file for each package, why not an index file too?

This would eliminate the security concerns (as they would be generated by the package maintainer), eliminate the hardware requirements (as searching would be done on the end-user's computer), and make life better overall.
_________________
I don't believe in witty sigs.

rac · Posted: Wed Jul 10, 2002 6:31 pm Post subject:

delta407 · Posted: Wed Jul 10, 2002 6:33 pm Post subject:

It is rare that USE flags dictate the files produced. USE flags (usually) specify functionality to ./configure, which produces the same set of files (although the files are different, of course). And again, since the package maintainer would be making the index files, if their package for whatever reason had files that depended on the USE flags they could set their USE flags to generate all the possible files, or hack the index file by hand.
_________________
I don't believe in witty sigs.

rac · Posted: Wed Jul 10, 2002 6:42 pm Post subject:

Spark · Tux's lil' helper Joined: 30 Jun 2002 Posts: 87

To me delta's suggestion sounds a whole lot more reasonable. =) Sure it would miss some very rare occasions (probably) but at least you would have those file indexes for every package _and_ it would be a lot less work.

BTW, what is epm good for? =)

Naan Yaar · Bodhisattva Joined: 27 Jun 2002 Posts: 1549

We already generate the file index and put it in the CONTENTS file in /var/db... So, in essence, this information is already there at the build site.

iplayfast · Posted: Thu Jul 11, 2002 2:05 pm Post subject:

[quote="klieber"]

klieber · Posted: Thu Jul 11, 2002 2:09 pm Post subject:

delta407 · Posted: Thu Jul 11, 2002 2:55 pm Post subject:

Naan Yaar · Bodhisattva Joined: 27 Jun 2002 Posts: 1549

Yeah, I do know that

What I was alluding to is "at least" dumping CONTENTS files from gentoo test build boxes to a web site, even if we did not really want to put this in portage. Of course, if we make this part of portage, developers can populate whatever file is designated for this purpose from a build (using find) or a merge (from CONTENTS).

We could create indices for executables, libraries, doc., etc., based on a master file list generated as described above and the directory into which things are installed as described in the file list.

Klavs · Guru Joined: 22 May 2002 Posts: 536 Location: Denmark

As the guy who started this discussion, I'm pleased to see as much interest for the idea - which something I would very much like to see made possible, preferrably implemented in portage - automatization is good :-)

Perhaps we should agree on the different solutions people prefer and make a poll and see the results?
_________________
Best regards,

Klavs Klavsen
Denmark

Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38.

delta407 · Posted: Thu Jul 11, 2002 7:27 pm Post subject:

While klieber's suggestion (manually specifying all the executables) is practical, it is limited (only executables, not libraries, include files, etc.) and requires more work -- the latter being the main reason no one will want to go for it.

Since Portage has sandboxing, it is trivial to generate an index of the files a package supplies. Most of the time, they will be the same, regardless of USE settings. But, for the times that they are not, we could use a dependency-like syntax (i.e. "variable? (/path/to/optional/file)" or something like that). That would make it automatic for 90-some percent of the ebuilds, and relatively easy for the minority.

I don't see much to vote on, other than who files a Portage feature request with Bugzilla.

_________________
I don't believe in witty sigs.

Klavs · Guru Joined: 22 May 2002 Posts: 536 Location: Denmark

I will be pleased to do that :-)

_________________
Best regards,

Klavs Klavsen
Denmark

Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38.