Dnia 10-03-2008, pon o godzinie 15:14 -0700, Cameron Dale pisze: > On 3/9/08, Mateusz Poszwa <[EMAIL PROTECTED]> wrote: > > Advantage is that it deletes&links only packages common for both caches. > > Unfortunately it runs rather slow, and requires additional dependency. > > What is more, it is not safe, because if files are on different > > filesystems or machines it produces symbolic links instead of hardlinks. > > That might still work, as long as the symlinks are in the apt cache. > Symlinks in the DebTorrent cache will definitely not work, but I'm not > sure how apt will behave when there are symlinks in its cache.
Symlinks in APT's cache do work. Anytime I run Finnix (a Debian-based LiveDistro) I symlink all packages from both caches (lots of 'already exists' messages) to ramdisk in order not to fetch them again. Dnia 10-03-2008, pon o godzinie 15:14 -0700, Cameron Dale pisze: > That's pretty much what I was thinking of too. Except for the "names > of files are usually slightly different" part, which I don't see ever > happening. Why would the package file be named differently in apt's > cache than in DebTorrent's? I have exaggerated, sorry... Some of package files (about 20% of mine) do have different names though. Examples (from APT's cache): anjuta_2%3a2.3.5-2_i386.deb autogen_1%3a5.9.4-1_i386.deb automake1.4_1%3a1.4-p6-12_all.deb bsdutils_1%3a2.13.1-2_i386.deb busybox_1%3a1.1.3-5_i386.deb cpp_4%3a4.2.2-2_i386.deb gcc_4%3a4.2.2-2_i386.deb genisoimage_9%3a1.1.6-1_i386.deb gimp-data-extras_1%3a2.0.1-3_all.deb iceweasel-l10n-pl_1%3a2.0.0.12+debian-1_all.deb imagemagick_7%3a6.3.7.9.dfsg1-2_i386.deb login_1%3a4.0.18.1-7_i386.deb mkisofs_9%3a1.1.6-1_all.deb nfs-common_1%3a1.0.10-6+etch.1_i386.deb openoffice.org_1%3a2.3.1-5_i386.deb #and other OOo packages passwd_1%3a4.0.18.1-7_i386.deb pciutils_1%3a2.2.10-1_i386.deb procps_1%3a3.2.7-3_i386.deb wodim_9%3a1.1.6-1_i386.deb xorg_1%3a7.2-5_all.deb #and other xorg and xserver packages Difference between names is a consequence of /[:digit:]%3a/ strings just after "pkgname_". I don't know where they come from, but i think APT's developers know. Links of such packages would not work, I have just checked it. Dnia 10-03-2008, pon o godzinie 15:14 -0700, Cameron Dale pisze: > On 3/9/08, Mateusz Poszwa <[EMAIL PROTECTED]> wrote: > > I wonder if there is a method of making apt try creating hardlink before > > making actual copy of package. This would be (IMO) the best solution. > > I don't believe there is, although as I mentioned in my previous mail > to this bug, you can make apt not create a copy of the file in it's > cache at all. Not ideal, but still a possible solution. > > Cameron Well, in my opinion this solution is DebTorrent only as APT would no longer care about cache, and DebTorrent would care only about its part of APT's cache (in this case entire APT's cache) and its own. :( It would be great if there was a method to tell APT behave like that only for DebTorrent origned packages (at least I don't know any). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
