[packagekit] some thinking on pkgenpack
Zhu, Peter J
peter.j.zhu at intel.com
Thu Sep 3 06:01:31 PDT 2009
I just tried pkgenpack and have some thinking on its implementation.
1. how is /var/lib/PackageKit/system.package-list maintained? This file is as default input as exclude file list. That file is a package-ids for all installed/available pkgs. I'm confused by this and actually don't understand this. It seems exclude all packages for a service pack but actually it's NOT. So my question is when&how this file is created and maintained?
2. why do we really need this file as default exclude list? Actually it's NOT uncommon we need package all packages and dependencies to a service Pack. So I suggest if we don't provide such input, we just ignore it and set exclude list as NULL. If we really need remove something from the pack, we can let users define it.
3. currently it uses PK_FILETER_ENU_NONE to resolve package id for a input --package. It has a side effect that if the repo is updated, it would NOT download available updated(newest) package from repo into this service pack for a installed package. But since our source for the service pack is a repo, we should download any package available in the repo for a given input --package. I want following behavior(I guess others want this as well) Seem we should use PK_FILTER_ENUM_NEWEST here, not sure if it's correct.
make is NOT installed, make-3.81-9 from repo is downloaded
make-3.81.9 is installed, make-3.81-9 from repo is downloaded
make-3.61.7 is installed, make-3.81-9 from repo (if repo has this updated) is downloaded
4. we should add support --package=InputFile which provides a list of packages want to be packed. This is especially if we want to provide a service package which have multiple packages together (NOT dependent with each other directly) to fix a CVE issue or a bug.
5. we might add some summary info to a metadata.conf for this service pack.
6. can we have gpk-update-viewer to work with service pack and let it read summary info from metadata.conf? That's much more friendly for a normal user that's NOT a linux geek than just changelog for each distinct package. On how to read that summary info, NOT sure where is appropriate place to define it, a new backend plugin or just let PackageKit do it directly.
More information about the PackageKit