You are not logged in.

#1 2005-08-19 17:06:11

Pajaro
Member
Registered: 2004-04-21
Posts: 884

more about the same

context
a big package has been modified. It had a bug. That was fixed changing only one config file. You maybe not noticed the bug, because it didn't affected your machine. You have to download and install the whole package again.

proposed solution
implement a patch system in pacman, so that u have to download just that config file when u do the next upgrade instead of the whole package.

how?
automatize the comparisson between two releases of a package, so that when u run makepkg --compare-with-previous it does this process. Then you have two files:
pkgname-pkgver-pkgrel.pkg.tar.gz
pkgname-pkgver-pkgrel-prevpkgrel.patch.pkg.tar.gz

then, if you have installed pkgname-pkgver, when there's a new pkgrel pacman checks if the size of the patches to install is smaller than the last package version itself, and if that is the case it downloads and installs the required patches instead of the whole package.

patch.pkg.tar.gz files should also include a metainfo (a .DELETE file in the root like the .FILELIST or .PKGINFO files) about files to be deleted.

a --ignore-patches option should also be added to pacman so that if u erased some files by error u can make sure u restore them.

I find it simple enough and very usefull.

Offline

#2 2005-08-19 19:56:33

paranoos
Member
From: thornhill.on.ca
Registered: 2004-07-22
Posts: 442

Re: more about the same

I like the idea, but I think it will be put off until there are enough developers to handle it. We need to change pacman and makepkg, we need more server space.

The more I think about it, the less I think it will work. Patches work great for source, but let's say there's a new kernel package ... you wouldn't be saving too much by getting just the changed files. The kernel package is just a big kernel image, with a lot of modules.

I think this would work better for things like xorg, but even then, xorg is moving towards modularization, so hopefully we'll be able to split it up into separate packages.

really, if your bandwidth is limited, and you don't find an update important, ignore it.

lol i wish i could take back my vote. i hate that.

Offline

#3 2005-08-19 20:07:53

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: more about the same

This was brought up ages ago, and from what I recall, here's what we gain:
- Vastly increased complexity (read: against the Arch philosophy)
+ Slight savings on bandwidth for large packages

Offline

#4 2005-08-19 21:03:11

cactus
Taco Eater
From: t͈̫̹ͨa͖͕͎̱͈ͨ͆ć̥̖̝o̫̫̼s͈̭̱̞͍̃!̰
Registered: 2004-05-25
Posts: 4,622
Website

Re: more about the same

yeah. this should go into the wiki faq...
one of those things that new people bring up every once in a while..and has been flogged over so many times, that I think my flogging stick is broken and in need of repair..


"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍

Offline

#5 2005-08-20 08:44:57

Pajaro
Member
Registered: 2004-04-21
Posts: 884

Re: more about the same

phrakture: I don't see bastly increased complexity. Not in programming and not in understanding.
Patch routines are the same than normal package routines, but instead of first deleting the package, just delete the files in the .DELETE file.
And about complexity of this idea by itself... I don't find it complex, and maybe if my leader test had given me einstein i could have thought that it's just me who can understand that, but that gaved me teresa de calcuta wink

cactus: i'm not new people, but i'm very busy, so ill really appreciate anything that could result in a time reduction.

Offline

Board footer

Powered by FluxBB