On Sun, Dec 26, 2021 at 9:18 PM Till Wegmueller <[email protected]> wrote:
> Hey Tim > > You basically need to do what you are doing, but you can limit your > search to local with -l parameter to pkg search. That would result in > your local leaf packages. To get the full list for OI, the simplest way > is to grep the Makefiles for 32bit builds. They are explicitly mentioned > there. From what I remember it should only be library packages and big > hitters like libreoffice. > > There is a feature in omnios PKG which we could port at some point > (autoremove) and one could use the python API to write a script to do > that. But that would also call a lot of search queries. > It would be very nice as long as it does not work like APT's autoremove :p this one is really a pain... > > -Till > > On 26.12.21 15:20, Tim Mooney via oi-dev wrote: > > In regard to: Re: [oi-dev] elegant way to get leaf packages?,...: > > > >> I am not sure I understand your question. Please clarify. > > > > I'm using "leaf" in the same sense as in a computer science tree > > structure; a node that does not have any descendants. > > > > https://en.wikipedia.org/wiki/Tree_(data_structure) > > > > A tree isn't the best model for package dependencies; a directed graph > > is better, but the terminology for a node with no exiting vertices > > isn't as clear, so I used "leaf" thinking everyone would understand > > what I was asking for. Sorry if that just made things worse. > > > > A package like 'glib' or 'python-39' have many other packages that depend > > upon them. glib and python-39 are *not* leaf packages. > > > > An example of a 'leaf' package would be 'media/vlc'. There are > > (currently) no other OI packages that list media/vlc as a dependency. > > Leaf packages are typically "end user applications", but even something > > like 'editor/vim' is not a leaf, because it has at least one real package > > (editor/gvim and SUNWvim) that depends upon it. The distinction is a > > little fuzzy here because it also has 'mate_install' and 'server_install' > > as dependencies, but for my purposes I wouldn't count those. > > > > My reason for asking is that I wanted to get a complete list of all > > leaf packages for OI, and then see which of those packages still ship > > 32 bit binaries. I'm just trying to get an idea of easy components for > > conversion to be 64 bit only. > > > >> pkg exact-install <somepackage> installs a package but removes all > >> "leaf packages" (?) that are not a dependency of the given package. > > > > Thanks for the suggestion about exact-install, but for what I'm trying to > > identify, it's not really an option. It only looks at a portion of the > > dependency graph. > > > > As I said in my original question, I know how to generate the list using > > a brute force method. I was just wondering if there was a better method > > that doesn't require running hundreds or thousands of 'pkg' commands to > > find all the leaf nodes. > > > > Thanks, > > > > Tim > > > >>> All- > >>> > >>> Is there an elegant way using pkg (or some other method) to get all > >>> OpenIndiana "leaf" packages, i.e. packages that are not a dependency of > >>> some other package? > >>> > >>> I know how to get this using a brute-force method that is essentially > >>> > >>> all_packages=`pkg list -a | some filtering here` > >>> for p in `echo $all_packages` > >>> do > >>> pkg search -r -o pkg.name "depend:require:$p" > depends-upon-$p > >>> done > >>> > >>> I'm just wondering if there is a more clever, or perhaps less intensive > >>> on the publisher server, way to get the same info? > > > > _______________________________________________ > oi-dev mailing list > [email protected] > https://openindiana.org/mailman/listinfo/oi-dev > -- --- Praise the Caffeine embeddings
_______________________________________________ oi-dev mailing list [email protected] https://openindiana.org/mailman/listinfo/oi-dev
