Dan McGee wrote:
> On Fri, Jan 2, 2009 at 3:12 AM, Allan McRae <allan at archlinux.org> wrote:
>
>> Changelogs and install files were getting extracted into the local
>> db folder before it was manually created. This created issues for
>> uses with 0077 umasks and was highlighted with the new sudo handling
>> of umasks (FS#12263).
>>
>> This moves the local db creation to its own function which is called
>> before the start of package archive extraction. Also, added a check
>> that the folder is actually created.
>>
>> Signed-off-by: Allan McRae <allan at archlinux.org>
>> ---
>> lib/libalpm/add.c | 10 ++++++++++
>> lib/libalpm/be_files.c | 24 +++++++++++++++++++++---
>> 2 files changed, 31 insertions(+), 3 deletions(-)
>>
>> diff --git a/lib/libalpm/add.c b/lib/libalpm/add.c
>> index eef7aab..c200c3c 100644
>> --- a/lib/libalpm/add.c
>> +++ b/lib/libalpm/add.c
>> @@ -696,6 +696,16 @@ static int commit_single_pkg(pmpkg_t *newpkg, int pkg_current, int pkg_count,
>> }
>> }
>>
>> + /* prepare directory for database entries so permission are correct after
>> + changelog/install script installation (FS#12263) */
>> + if(_alpm_db_mkdir(db, newpkg)) {
>> + alpm_logaction("error: could not create database directory %s-%s\n",
>> + alpm_pkg_get_name(newpkg), alpm_pkg_get_version(newpkg));
>> + pm_errno = PM_ERR_DB_WRITE;
>> + ret = -1;
>> + goto cleanup;
>> + }
>>
>
> If we have a failure between here and when we actually write out the
> DB entry, what happens?
If a failure occurs, we have an empty folder or a folder with only
.changelog and .install in it (which we could have ended up with
anyway). I think dealing with failure here probably needs a clean-up
anyway. As far as I can tell, if installing a package fails partway
through the archive extraction, we end up with a lot of untracked files
on the system. We should probably either keep a list of files installed
so far so we can revert it or push the list to the db as extraction
happens so we know their owner (which removes abstraction...).
> I was hoping we would take the "extract the
> changelog/install file at later time" route, but that is definitely a
> bit more of a hassle...
>
But then we would need to re-deal with setting up reading from the
archive file which seems a bit overkill.
> Calling a function _alpm_db_mkdir() ties us awfully tight to the
> existing be_files implementation, although I'm sure most of this code
> will need a lot of work if we decide to change things up.
>
Sure, but as I said above, I think this whole area could do with a
change. The patch I provided was what I think is the best way to deal
with the issue in a maint release.
Allan