Bug 381311

I believe there is a way to disable this for installation, Stano?

You can use the RepoInfo API to disable the behavior for a repository.

Shouldn't we find a better location for the caches than tmp/AP_0xNNNNNNNN?
These dirs should not exist after YAST ended. 

*** Bug 382694 has been marked as a duplicate of this bug. ***

maybe this is also related to bug #379922, because if we attach again network source, this directory is used and burl backend use file with bad checksum as timestamp for last downloaded file and server return 304 (not-modified). And because user response during disattached state, it is not possible delete file.

Cache directory is /var/cache/zypp by default. /var/adm/mount is directory to which is create tmp AP_0XXX directory where is something mounted (for remote repository is place where is temporary stored downloaded files). Now it looks like that only in past some directory remain unattached, because now after each session this directory must be removed.
Please try clean /var/adm/mount directory and check if something stay here after some refresh/install/other actions.

No, it doesn't. /var/adm/mount is all clean now (pre-Beta2)

(In reply to comment #7 from Klaus Kämpf)
> No, it doesn't. /var/adm/mount is all clean now (pre-Beta2)
> 

Ok, this artefact may relate to option which doesn't remove attach point, which is now optional.

So close as fixed.

still there, updating via ftp from stable right now (factory update):

Fatou:/var/adm/mount # du -sch *
506M    AP_0x00000001
506M    total

OK. I need few info:
1) Is this directory present before you update?
2) stable mean 10.3? If yes this can be problem, if old version create permanent directory, new version is not allowed to delete it (because don't know that previous version create it)
3) please attach log
4) try delete it and make some action via this ftp (install something new e.g)

I ran into the problem during a 10.3->11.0Beta1 upgrade.
I now did two 11.0Beta1->11.0Beta2 upgrades and didn't run into this bug.

(In reply to comment #11 from Klaus Kaempf)
> I ran into the problem during a 10.3->11.0Beta1 upgrade.
> I now did two 11.0Beta1->11.0Beta2 upgrades and didn't run into this bug.
> 

So it looks like that without 10.3 patch is not possible avoid it. Maybe add some note to release about delete all AP points in /var/adm/mount if user want upgrade from 10.3 to 11.0 .

no, I'm not talking about 10.3
I'm talking about updating from 11.0-post-beta1plus (last friday or monday)
to the current state (almost beta2).

Yes, /var/adm/mount is really being cleaned _after_ the update is finished.
But that was never my issue.

The issue is: during the update, all the rpms stay there until the update
is finished. For my system this sums up to almost 3Gb while I have only
2.8Gb free space below / ...

(In reply to comment #13 from Ruediger Oertel)
> no, I'm not talking about 10.3
> I'm talking about updating from 11.0-post-beta1plus (last friday or monday)
> to the current state (almost beta2).
> 
> Yes, /var/adm/mount is really being cleaned _after_ the update is finished.
> But that was never my issue.
> 
> The issue is: during the update, all the rpms stay there until the update
> is finished. For my system this sums up to almost 3Gb while I have only
> 2.8Gb free space below / ...
> 

OK, so problem isn't that RPMs stay in cache, but that /var/adm/mount is not big enought to save whole downloaded RPM.
Now zypper allow (but undocumented) disable caching in /var/cache/zypp...but still all rpms stay in mounted "internet repository".
I fix it. (and also low severity, because this is not blocker)

done in svn.
I test it on kde4 installation and no more then one package is here. If this one which is downloaded is problem, then help only some redesign of remote downloading.

thanks, that's perfect for me!

keeping the last one (or even last two) downloaded rpms in the cache
is perfectly normal. I just could not understand keeping 1700 rpms there ...

done in libzypp-4.19.0