GNOME Bugzilla – Bug 337069
Patch for FilterEbuild.cs to include install time and content summary
Last modified: 2006-05-01 19:37:02 UTC
The attached patch will add two properties. "installtime" is the time the package was installed. "installedobjects" is a summary of the total bytes, files and directories installed.
Created attachment 62686 [details] [review] FilterEbuild-installproperties.patch
Created attachment 62689 [details] [review] FilterEbuild-installproperties.patch Must have had a brain lapse... Changed installed bytes, file, dirs summary to not be searchable. No reason to search this.
With the "string[] path = file.Directory.FullName.Split ('/')" line, can you give an example of the kind of path you're breaking down? Because FileInfo and DirectoryInfo have a lot of utility functions on them so that you don't have to do that kind of parsing of paths yourself. Also, is having a string of byteCount + " bytes, " + fileCount + " files, " + dirCount + " directories" helpful? Generally we try to avoid putting structured items like this in the index if they aren't real text. I'd rather we do "fixme:byte_count", "fixme:file_count", "fixme:dir_count" if they are going to be useful to applications.
I agree with the byte, file, dir count thing. I thought about that too. I'll make the change. The path is like /usr/portage/x11-base/xorg-server/xorg-server-1.0.2.ebuild. I need the "x11-base" to tell me which category to look for. I looked in the Mono API and I saw FileInfo.Directory, but I need the parent of the FileInfo.Directory, which I could not see. I would very much like to not parse if you could point me in the right direction.
Ok. You can do "file.Directory.Parent.Name". That should give you "x11-base".
Created attachment 62694 [details] [review] FilterEbuild-installproperties.patch Moved byte, file and directory counts in separate unsearchable properties. Change parsing of paths to use file.Directory.Parent.Name. Not sure how I missed that in the API... I even thought to myself to look for "Parent" ... need some sleep....
Just curious, if I just have some ebuild in my home directory and I am not a gentoo user (or user of any system using ebuilds), then will this filter work correctly and extract information about the ebuild ?
Good question. Yes it will. I intended the collection of installation information to be optional. I am assuming the following lines will not throw an exception if a file and/or directory in the path does not exist: FileInfo contents = new FileInfo(...); if (contents.Exists()) { ... } This is meant to check if that ebuild is installed. If it is then the contents file is parsed to determine the contents (files, directories, size). Otherwise these properties are ignored and processing continues as the current version. I took another look through the code and its possible if a file listed in the CONTENTS file has been removed there could be an exception. Added a check for this.
Created attachment 62697 [details] [review] FilterEbuild-installproperties.patch Check that the files that the CONTENTS file says are installed are actually installed before getting the length.
(In reply to comment #8) > Good question. Yes it will. I intended the collection of installation > information to be optional. I am assuming the following lines will not throw Hmm... whenever some filter tries to gather data outside of the file, there are some corner cases when things dont work. E.g. if some change happens to the external data source that wont be picked up by beagle and information about the file might be incorrect. However, from the structure of the filter (and the near-0 knowledge of ebuilds that I pocess) looks like that would never happen for ebuilds and everything would be fine. Or am i wrong ? E.g. what if some ebuild user just downloads the ebuild and doesnt install it immediately. Beagle picks it up, installs it without any installation info. Then the ebuild gets installed. So clearly the information about the ebuild wont contain any of the installation information. This isnt so bad ... the lack of information. What would be bad if something happened the reverse way, some change happens to the installation information w/out touching ebuild and as a result the information stored in the index gets invalidated!
Good point. I thought it would be nice to make the beagle ebuild support similar to other Gentoo portage indexing solutions, such as what version is installed, how large is it, how large is the download size, etc. All of these solutions have similar problems, you can install or uninstall and the index is invalid. Users know this and will rebuild the index. The difference here is that all of those solutions rebuild the entire index each time, while beagle only does so when changed. Any recommendations? BTW, this also proded my memory that some of the other index solutions provide the size of the downloaded files. I added this too, should I submit a separate bug?
(In reply to comment #11) > Good point. I thought it would be nice to make the beagle ebuild support > similar to other Gentoo portage indexing solutions, such as what version is > installed, how large is it, how large is the download size, etc. All of these > solutions have similar problems, you can install or uninstall and the index is > invalid. Users know this and will rebuild the index. > The difference here is that all of those solutions rebuild the entire index > each time, while beagle only does so when changed. Any recommendations? Filters are dumb - they can only extract information from whatever file is thrown at them. Whenever there is some meaning to the file, some contextaul information, some additional processing to gather data from other sources, handling changes to the file or other parts of the filesystem, I tend to think about a Backend (aka Queryable in beagle lingo). You can try that ... Since the data in question here is relatively static and system-wide, you might want to build a static index on the installation information and schedule a cron job everyday night to update it. Its no better than the other indexing solutions... and I know nothing better. > BTW, this also proded my memory that some of the other index solutions provide > the size of the downloaded files. I added this too, should I submit a separate > bug? Since Joe hasnt given a final-go yet, sneak it here itself. He is busy fixing bugs and won't notice ;)
I think investigating into writing a Queryable would be best. This is outside the scope of the filter. The point of beagle is to have quick updates of information, it is not time consuming to gather this installation information at the time of the query and it would give a better experience. I will remove it and file another bug for the download info. The download info on the other hand is directly tied to the ebuild, so much so that a hash is made of the files and if they differ it is considered an error. That should be within the design of beagle. At least the code can be used in the Queryable.
Created attachment 62882 [details] [review] FilterEbuild-installproperties.patch Patch to include installation properties ONLY if the ebuild is in the /var/db/pkg directory, which is the Gentoo installation "database". After much consideration of how Gentoo tracks software installs I would be extending a static queryable to augment information in the Hit that should not change once the ebuild makes it into the installation database. Seemed like a lot of extra work that just updating the filter could do. Including /var/db/pkg in the static queryable answers the previous concerns. Please consider this patch against FilterEbuild.cs to record install information ONLY for .ebuild files in the installation database. Note that Gentoo copies the ebuild file into this directory after installing. Thanks.
Oh yes, the patch also changes the version to use NewKeyword instead of NewUnsearchable for the same reasons the debian filter does this. Adds recording of ".desktop" files in the install so a client may opt to provide a means of launching the applications.
Created attachment 64487 [details] [review] FilterEbuild-installproperties.patch Updated for latest CVS.
Checked this in, thanks!