Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Save bandwidth with diff/xdelta
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
AndrewBirkett
n00b
n00b


Joined: 21 Apr 2003
Posts: 3
Location: Edinburgh, Scotland

PostPosted: Mon Apr 21, 2003 10:09 pm    Post subject: Save bandwidth with diff/xdelta Reply with quote

If I upgrade from emacs-21.2 to emacs-21.3 I have to download the whole new 20Mb tarball, despite there being a 1Mb xdelta from my existing version.

I can imagine an extension to the ebuild system which allows you to express the following: "If you have emacs-21.2 then grab the 21.2-to-21.3 delta and use it to generate emacs-21.3.tar.gz. Otherwise, just download emacs-21.3.tar.gz as normal"

Sure, most projects don't provide diffs but biggies like kernel and GNU projects like emacs, gcc and others do. It'd relieve some of the load on the source archives, and it'd be great for those of us without a fast connection.

What I'm suggesting is something which you could add to a particular ebuild script, which said where to get the diffs between the last two or three releases of the project. If the ebuild didn't include some "CAN-USE-DIFFS:" lines, then you'll just have to download the whole new version of the package.

Apologies if this is a FAQ. I looked around for a while, but 'diff' and 'patch' are poor keywords. If this isn't a crazy idea, I'll could dig around in the code and see if there's an easy and clean way to add it.
Back to top
View user's profile Send private message
puddpunk
l33t
l33t


Joined: 20 Jul 2002
Posts: 681
Location: New Zealand

PostPosted: Tue Apr 22, 2003 2:08 am    Post subject: Reply with quote

This was being discussed on the Gentoo-dev mailing list a little while ago, the problem was, nobody could come up with a sturdy way of implimenting it. Perhaps you would like to add your thoughts?
Back to top
View user's profile Send private message
AndrewBirkett
n00b
n00b


Joined: 21 Apr 2003
Posts: 3
Location: Edinburgh, Scotland

PostPosted: Tue Apr 22, 2003 6:43 am    Post subject: Reply with quote

Thanks - I eventually found my way to http://bugs.gentoo.org/show_bug.cgi?id=11470, which is pretty close to what I was suggesting.
_________________
- http://www.nobugs.org -
Back to top
View user's profile Send private message
aethyr
Veteran
Veteran


Joined: 06 Apr 2003
Posts: 1085
Location: NYC

PostPosted: Tue Apr 22, 2003 6:02 pm    Post subject: Reply with quote

I know this has been discussed in the past, but I feel that this is an important feature (that is already implemented by other source-based distributions such as sorcery/source mage) that cannot be continually glossed over.

I realize that the devil is in the details, but I feel that this would be a huge advantage for Gentoo in terms of giving users the "power of the source". And not even for slow connections, I started downloading linux-2.4.20.tar.bz2 (26.2mb) last night on my broadband connection and it was taking forever at 13kb/sec. I realized that I had a 2.4.19 tarball sitting around, so I grabbed the patch instead., the patch-2.4.20.tar.bz2 is 4.0mb. That's 1/6 of a difference. That's huge.

I think that some type of "upgrade path" table (contained in a file in the portage directory) needs to be built (possibly manually by the package maintainer?) that basically says something along the lines of:

patch to get to newest version - z - size
patch to get to intermediate version - y - size
current version - x

take the sum of the sizes of the patch files to get from x to z (in this case size of the y-patch), check if it's less than the size of grabbing z, if it is, then patch x to y, then to z, if not, download z.

The size of files is already contained in the portage tree, so it's not a problem finding those out.

In the above scenario, there could be any number of intermediate versions, as long as the total patch size was less than the size of the newest version, and we could forseeable upgrade to any package along the path.

Let's look at a more concrete example, the kernel.

Let's say we have an "upgrade path" table that looks like this

patch-2.4.20.bz2 -> linux-2.4.20 (4M)
patch-2.4.19.bz2 -> linux-2.4.19 (4.5M)
patch-2.4.18.bz2 -> linux-2.4.18 (807k)
patch-2.4.17.bz2 -> linux-2.4.17 (388k)
patch-2.4.16.bz2 -> linux-2.4.16 (6k)
patch-2.4.15.bz2 -> linux-2.4.15 (1.4M)
patch-2.4.14.bz2 -> linux-2.4.14 (560k)
...

Let's say we're currently running 2.4.14, and we do "emerge -p vanilla-sources"

First we see we're going to go to kernel 2.4.20, which has a size of 26.2M. Before doing that, we check our upgrade path, and see that 2.4.20 is available in our path (being at the top position). Once we see it's available, we check to see how much it "costs" to get there. We simply add up the "cost" of each patch:

0.56 + 1.4 + 0.006 + 0.388 + 0.807 + 4.5 + 4.0 = 11.661

11.661 costs less than 26.2 so we decide to follow the upgrade path.

The path is already set up for us, so we just advance step by step up the path, downloading, patching, downloading, patching, along the way, all inside a temporary directory. Once we have our final tarball, we're good to go. And we've saved 50% of the bandwidth, not too bad considering the 2.4.14 kernel is a full year older than the 2.4.20 kernel, the closer you are in the path, the less expensive it is to move up the path.

I realize that there's no code whatsoever in this idea, but I think it gives a feasible framework to work with.
Back to top
View user's profile Send private message
AndrewBirkett
n00b
n00b


Joined: 21 Apr 2003
Posts: 3
Location: Edinburgh, Scotland

PostPosted: Tue Apr 22, 2003 7:44 pm    Post subject: Reply with quote

That's a nice idea. Though I think I'll try coding up a simpler "upgrade from previous version only" as a test case .. since I'm more likely to have time to complete that.

Earlier today, I thought that it'd be nice if this feature was mostly hidden inside the 'retrieve tarball' code. So, you can get the latest tarball by downloading it, or you can get it by downloading a patch to an existing tarball. Either way, you end up with the latest tarball on your disk and ebuild carries on from there. This keeps the changes to ebuild very localised. Also when you clean out /usr/portage/distfiles you'd only need to keep the latest version rather than a chain of patches. After all, the plan is to conserve bandwidth, not disk space.

However, the patched tarball is unlikely to have the same md5sum as the official one, unless you use exactly the same gzip/bzip options and the file timestamps match. So, maybe it's not such a clever idea after all.
_________________
- http://www.nobugs.org -
Back to top
View user's profile Send private message
aethyr
Veteran
Veteran


Joined: 06 Apr 2003
Posts: 1085
Location: NYC

PostPosted: Tue Apr 22, 2003 11:58 pm    Post subject: Reply with quote

it might be easier to implement it as a seperate script for now rather than try to modify portage directly (i.e. something that could be included in gentoolkit).

Quote:

Earlier today, I thought that it'd be nice if this feature was mostly hidden inside the 'retrieve tarball' code. So, you can get the latest tarball by downloading it, or you can get it by downloading a patch to an existing tarball. Either way, you end up with the latest tarball on your disk and ebuild carries on from there. This keeps the changes to ebuild very localised. Also when you clean out /usr/portage/distfiles you'd only need to keep the latest version rather than a chain of patches. After all, the plan is to conserve bandwidth, not disk space.


I think you'd still need to list somewhere what patch file to actually grab, hence my idea of an update table that you could move to any position on. If I understand you correctly, you'd have some kind of patch information in the ebuild? That seems like it would work too.

I think this is definately something that is doable, like I mentioned before, other source distributions are already taking advantage of the ability to use small patches on large packages.

I think if you could get some workable test cases, it would be easier to get the devs to integrate it into portage, I know people have been asking about this for a long time.
Back to top
View user's profile Send private message
Thulle
n00b
n00b


Joined: 11 Nov 2002
Posts: 55

PostPosted: Mon May 05, 2003 3:04 pm    Post subject: Reply with quote

Wouldn't it be an good idea if the users could choose wich idea to use?
For modemusers with some drivespace, it would be great with those upgradepaths, but broadbandusers with small drives would probably choose to save diskspace and instead utilize the connection they paid for.
Maybe an configurable percentagevalue of wasted space (old tar+patches compared to new tarball)?
Back to top
View user's profile Send private message
aethyr
Veteran
Veteran


Joined: 06 Apr 2003
Posts: 1085
Location: NYC

PostPosted: Mon May 05, 2003 5:02 pm    Post subject: Reply with quote

Thulle, no actually, it wouldn't be better to give users choice which method they use.

Why would you ever opt to download 20mb over 10mb? Even with broadband, that's still a 2x time difference.

You'd still end up with the same tar.bz2 in the end. All the incremental patches would be deleted, so the disc space taken up would be exactly the same as if you had just emerged a new version.

That being said, it would probably be good to cut it off somewhere, say if the costs of patching were more than half of the cost of downloading. Also, it might not be worth it if the new package download is less than a megabyte. Finally, keep in mind that not all packages post upgrade patches, some just give you new tarballs, so it would be unusable for those projects.
Back to top
View user's profile Send private message
dreamer3
Guru
Guru


Joined: 24 Sep 2002
Posts: 553

PostPosted: Sat May 10, 2003 1:05 am    Post subject: Reply with quote

aethyr wrote:
Finally, keep in mind that not all packages post upgrade patches, some just give you new tarballs, so it would be unusable for those projects.

Not unusable, merely more difficult (and if it was less than 1mb I wouldn't bother). But if it's 15 meg raw and a 540kb diff...

I like the idea of just keeping intermediate steps and then downloading whichever ones you need... the rsync/overwrite md5sums thing really has to be fixed/thought through for any of this to work as the tar.bz2 files we build ourselves are sure to not match the original downloads.

psuedo-code for diffing any project source
Code:

extract version-x
extract version-x+1
diff [right flags] x/ x+1/ > verion_x_to_x+1.diff
Back to top
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Sat May 10, 2003 3:01 am    Post subject: Reply with quote

A couple of problems you're going to run into- these are mostly gleamed from a night of screwing around generating a diff for openoffice...
Major diff's annoyances:
1) doesn't do jack about binary files, just states, the files differ. This ain't an issue for sources that lack binary files, but for say openoffice this is an issue. Further, unless I'm wrong (and I checked heavily into it), there really isn't anyway to tack binary data into a diff file. So you couldn't get away with just distributing a diff- you would likely do a tarball w/ a patch and binary files inside.
2) Diff doesn't like zero length files. This probably isn't an issue, but if you are diffing between 1.0 and 1.1, and 1.1 has zero length files in it that 1.0 lacks, diff doesn't do anything (actually if you're just doing diff -ur it will say it exists in one... if you're using -n (likely) it doesn't say anything).
3) not so much a diff issue, but a consideration- try generating a diff between kde 3.1 and 3.11 (as an example)- you'd expect it to be minor, but it's not so minor. Reason being, it seems a lot of the larger projects have auto-generation of files (xml files as an example)- so instead of getting just the changes between 3.1 and 3.11 for a file that may not have even changed, diff registers the file as basically being completely different. Meaning said file is actually a bit larger in diff format cause it encompasses both the old file and the new file (old for deleting said lines, new for adding said lines)- this actually is much more expensive in terms of size.

So that's already a pain in the arse, but if you're doing the patching at the time of untarring, as long as 1 and 2 are dealt with you should be fine. Downside being that every time you compile said package, it must repatch the source adding to the overall complexity/time.
Why not just download the diff, patch the distfile, then retar it you say? Heh heh... I've yet to get the md5sum to match.
1) if all that's changed on a file is it's date/permissions/non-data, diff ignores it. eg the data is the same, but the file attributes aren't...
2) Zero length files mentioned above.
3) If the developer created the tarball, then appended a file to it, that file isn't in it's normal place- it's appended. You would have to match this (basically impossible I think).

So to actually update the distfile (which in my books is a good idea despite it's thornyness), we need to match the patched source exactly to the target versions setup. Why would it be better to do distfile patching rather then doing the 'upgrade path'? Well....
1) upgrade path doesn't always exist/work. Kernel v2.4.11 or 2.4.12 you can't upgrade past IIRC as an example- so the v2.4.11/12 (which ever one it was) would have to have some way of saying, "um, no kiddies, no diff's allowed here...". Minor issue, but you get the idea.
2) One time annoyance of patching the distfile- after that (assuming one gets the md5sum exactly right), to emerge the distfile appears as the full source. This is preferable mainly cause that way emerge doesn't have to dink around w/ having the 12+ version patches cause a user hasn't downloaded a recent full source (less complexity is good). That and it means less modification to emerge (instead of every package emerge having to the diff check on it's sources, you just stick this modification in the fetch section).

There is the matter of generation of the diffs- this would basically be the developer's responsibility (you can't push it onto the servers most likely). Something could be automated to make it easier for the developers, but it would have to be something that isn't a pain in the butt for dev's to deal with. There also is the issue of getting the diff's onto the server- a developer doesn't neccesarily have to upload the source (an automated script grabs missing sources every couple o days), so how would diff creation be handled in such a scenario?

So yeah, that is my 2 cents in a semi-stream of thought rant. I personally would like to see this happen (tiz why I pestered dev mailing list with the distfile diff question), but the issues involved are annoying. Matching the md5sum strikes me as something that would be quite hard if not impossible for the majority of sources... Course that could be dealt w/ by having intermediate md5 sums (as in a patched v1.1 has this md5)... but that gets complex/burdensome/insane fast.


Last edited by ferringb on Sat May 10, 2003 3:19 am; edited 3 times in total
Back to top
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Sat May 10, 2003 3:05 am    Post subject: Reply with quote

Heh, while it's kind of responding to my own post, anyone curious as to why this would be a *good thing*- I created a fully working openoffice diff (well, diff, updated binaries files, and empty file listing), used it to modify/patch/recreate the recent oo source- total files downloaded were roughly 12mbs, which I could've pushed smaller by pulling apart zip files and grabbing a diff of the files in there...

Course the stupid thing doesn't match the md5sum, but neh- avoiding a 160+mb download on 56k is worth the md5 hassle...
Back to top
View user's profile Send private message
dreamer3
Guru
Guru


Joined: 24 Sep 2002
Posts: 553

PostPosted: Sat May 10, 2003 5:32 am    Post subject: Reply with quote

ferringb wrote:
Major diff's annoyances:
1) doesn't do jack about binary files, just states, the files differ. So you couldn't get away with just distributing a diff- you would likely do a tarball w/ a patch and binary files inside.

Looks like the diff output would have to be parsed and then one could use xdelta (haven't tried it just read about it in another thread) to diff binary files for potential savings there. Or just always include full copies of binaries. Correct, the final "differences" would have to be tarred.
Quote:

2) Diff doesn't like zero length files. This probably isn't an issue

I agree, a non-issue... haven't seen too many source packages with such files although a simple find command could locate all these and they could be tarred seperatly for every "diff" and quickly re-extracted to "patch" newer versions... not much cost in storing the file info for empty files.
Quote:
3) try generating a diff between kde 3.1 and 3.11 (as an example)- it seems a lot of the larger projects have auto-generation of files (xml files as an example)- so instead of getting just the changes between 3.1 and 3.11 for a file that may not have even changed, diff registers the file as basically being completely different.

Diff can produce formats other than RCS... some of which doesn't include the actual contents of all removed lines. I think those alternative formats could work well since we're just moving from one set of files we know exactly to another set... any patches a user wanted to apply would be done _after_ the package had been patched to the desired version. So we wouldn't need the cool "best guess" patching features that having context provide us...
Quote:
Downside being that every time you compile said package, it must repatch the source adding to the overall complexity/time.
If only the world were perfect...

Quote:
Why not just download the diff, patch the distfile, then retar it you say? Heh heh... I've yet to get the md5sum to match.

We can never expect it to... if retaring was ever to be a serious solution portage would have to know about it and rsync wouldn't overwrite the md5sums, or "rebuilt" md5s would have to be stored eleswhere (more plausable as it could be "hacked" on for us bleeding edge types)
Quote:
1) if all that's changed on a file is it's date/permissions/non-data, diff ignores it. eg the data is the same, but the file attributes aren't...

If the content hasn't changed and we're talking source packages I'm not sure we even care...
Quote:
2) Zero length files mentioned above.

Easy as discussed above.

Quote:
1) upgrade path doesn't always exist/work. Kernel v2.4.11 or 2.4.12 you can't upgrade past IIRC as an example- so the v2.4.11/12 (which ever one it was) would have to have some way of saying, "um, no kiddies, no diff's allowed here...". Minor issue, but you get the idea.

Just because the upgrade "path" isn't valid doesn't mean we should do anything different... they might still have a good reason for doing what they are doing. Portage handles "non-paths" by pinning versions of software that SHOULD not change... If Gentoo 1.4 can never go past kernel 3.2 (one day for one reason) then you pin it, not break the diff feature for a new Gentoo install who just happens to have the older kernel source on CD or local network...
Quote:
2) One time annoyance of patching the distfile - This is preferable

I agree that this is best.

Quote:
There is the matter of generation of the diffs- this would basically be the developer's responsibility (you can't push it onto the servers most likely). Something could be automated to make it easier for the developers, but it would have to be something that isn't a pain in the butt for dev's to deal with. There also is the issue of getting the diff's onto the server- a developer doesn't neccesarily have to upload the source (an automated script grabs missing sources every couple o days), so how would diff creation be handled in such a scenario?

Devs would have a utility to quickly create "full diffs" (that work around all the diff gotchas)... diffs would have to be stored and mirrored somehow like the distfiles themselves... since I don't know how that whole process works already I couldn't comment... I suppose put it on ibiblio or the master distfiles server and then the others would pick the file up when they mirror??

Quote:
Matching the md5sum strikes me as something that would be quite hard if not impossible for the majority of sources...

I'm getting tired of droning on here... see my next post.
Back to top
View user's profile Send private message
dreamer3
Guru
Guru


Joined: 24 Sep 2002
Posts: 553

PostPosted: Sat May 10, 2003 5:42 am    Post subject: Reply with quote

Regarding MD5 sums... if full support wasn't coded into Portage to track this in /usr/portage a seperate database (/var/db/patches?) could easily be used that fetch could check first or check if the main md5 compare failed... the md5s of "patched" sources could be stored there.

I think MD5's matching is a non-issue actually... the whole diff idea will take a lot to impliment anyway and without the Gentoo Devs support it will never work for the majority of ebuilds. Assuming we _do_ have their support then I only imagine portage would be changed to handle the MD5 variability.

Ok... lets assume they aren't that interested, or they don't have time for a while... it wouldn't be impossible to impliment a system outside of portage (provided we had some web space open to HEAVY usage). You would create and provide diffs for the largest packages first, followed by smaller. A special "fetch" command could be created that understood the system, would download all the necessary files, patch, place the new tarball in /usr/portage/distfiles, and update the md5s in /usr/portage. These md5s could also be kept track of so /usr/portage could be re-updated with the CORRECT md5s (after a sync for example).

Edit: Portage could then be hacked to have it's fetch functionality first call the "patch fetch" code and only try normal downloads if no suitable patches are found. Not sure how hard this would be to do... biggest problem is the storing and mirroring of diffs...
Back to top
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Sat May 10, 2003 8:50 am    Post subject: Reply with quote

I actually sat down and responded to each quote... but that got to long (droning as you said). Soo a couple of choice quote responses and some thoughts.
dreamer3 wrote:
Diff can produce formats other than RCS... some of which doesn't include the actual contents of all removed lines. I think those alternative formats could work well since we're just moving from one set of files we know exactly to another set... any patches a user wanted to apply would be done _after_ the package had been patched to the desired version. So we wouldn't need the cool "best guess" patching features that having context provide us...

Actually what I was talking about was unified diff- non-rcs. RCS appears to be considerably more efficient then a uni-diff, RCS overhead offhand appears to only have a 2-3 line overhead for each block/section of changes. Downside is getting patch and it to behave well.
dreamer3 wrote:
Just because the upgrade "path" isn't valid doesn't mean we should do anything different... they might still have a good reason for doing what they are doing. Portage handles "non-paths" by pinning versions of software that SHOULD not change... If Gentoo 1.4 can never go past kernel 3.2 (one day for one reason) then you pin it, not break the diff feature for a new Gentoo install who just happens to have the older kernel source on CD or local network...
Eh? 'non-paths'=?. Specifically, what I was getting at there is that there are instances where it is either not possible or viable to patch to the desired version. Hence the need for an ebuild to be able to specifically state, "Download the full source- no patching for this version". Unless you're getting at something else (correct me if I'm missing your desired point).
dreamer3 wrote:
Devs would have a utility to quickly create "full diffs" (that work around all the diff gotchas)... diffs would have to be stored and mirrored somehow like the distfiles themselves... since I don't know how that whole process works already I couldn't comment... I suppose put it on ibiblio or the master distfiles server and then the others would pick the file up when they mirror??

Basically quoting the info Jon Portnoy sent me when I asked about this on the dev list, a developer has the option of uploading the source to a directory on a server... from there, it's copied (presumably automated in someway- wasn't clear on this) to the master repository, then rsynced out to the rest of the world. As to if the dev's have access to some automated script for the upload, I have no clue. Also note, if they don't upload the source, an automated script grab's the source for missing src_uri's every few days and dumps them to the master repository.

Dealing w/ diff creation, one thing to be consider is that one can only expect a dev to create a diff from the most recent (say v1.50) version to the current ebuild he/she/it is creating (say v1.56). Problem that arises is dealing w/ a user who's downloaded (including patches) distfile isn't up to v1.50. Personally, I think when a new ebuild is submitted, if the dev creates a diff, the diff uri should be an entry in the ebuild. This way, if you have ebuild v1.4, via the portage tree you could track down (and download) the diff's for the various ebuilds working your way upto the desired version- basically aethyr's upgrade path, except tied to the ebuild. Downside to this is dealing w/ older ebuild versions being removed from the portage tree- I'd be inclined to say tough cookies mainly cause requiring a dev to maintain old diffs (deleting for instance) would seems like more administration then it's worth/they'll do. Course you could build some intelligence into the patch-grabber (with appropriate setup on the mirror side) that gets around this- I'd think that would be a pain to maintain/setup though.
dreamer3 wrote:
A special "fetch" command could be created that understood the system, would download all the necessary files, patch, place the new tarball in /usr/portage/distfiles, and update the md5s in /usr/portage. These md5s could also be kept track of so /usr/portage could be re-updated with the CORRECT md5s (after a sync for example).

Personally, I think that's more of a pain then it's worth. As I'd posted, a true (md5) recreation of the distfile tarball I'd love to see, but it ain't easily viable- so as you stated (which made sense), upgrade the sources version, if desired, retar and copy the recreated distfile to a directory (non-main distfiles dir).
Further, I wouldn't even remotely try to jam the user's patched distfile md5 into the portage tree- The portage tree (exempting local overlays), and by extension the distfile dir, are essentially distribution wide settings/files. Attempting to update/integrate system specific md5s/tarballs into it is counter-intuitive; maintain it outside of the rsynced tree/distfiles. Yes this is an extra tree, but it also simplifies it by not attempting to integrate md5sums back into a packages digest file. Alternatively, use overlay- this is it's intended purpose after all.

Other thoughts- anyone actually used xdelta? Up until about 5 hours ago I hadn't ever heard of/used it. Also, I think md5sum's SHOULD be generated locally after patching and storing a distfile- this would have to be a system specific thing due to the fact if user A) started from v1.0 and patched to v2 and then v3, and user B) started from v2 and patched to v3, there md5sums for the distfiles would be different. Mind you I'm not saying diff's shouldn't be md5sum'ed by the dev/gentoo, just the patched version that's generated locally.
That and anyone have any idea how/when older ebuilds are removed from the portage tree? Or if they even are on a regular basis?

EDIT: I removed a lil section about efficiency with this- this posting is huge enough already...
Back to top
View user's profile Send private message
vericgar
Retired Dev
Retired Dev


Joined: 13 Dec 2002
Posts: 79
Location: Spokane, WA

PostPosted: Sun May 11, 2003 5:31 am    Post subject: Reply with quote

From what I understand of the portage system, it shouldn't be to hard to implement this in the ebuild itself. The ebuild can dynamicly generate the SRC_URI, so I see no reason why this can't be hacked up to work in the ebuild without modifying portage itself... or even put into an eclass.

code-flow:

1) check if source tarball for lower versions exists, starting with the most recent and working the way back through the versions until it no longer makes sense to do patching to current (i.e. patches don't exist, or total of all patch files is more then new download, etc)

2) once patch path is found, add all patches to SRC_URI

3) when in src_unpack check to see if we are doing patches (flag set previously) and patch as necessary.

4) continue as normal

Now the MD5SUM would need to contain the MD5s of all the possible downloadable patches, but that isn't a biggie.
_________________
+~+ Sometimes a good ole loving kick is all it needs +~+
Back to top
View user's profile Send private message
dreamer3
Guru
Guru


Joined: 24 Sep 2002
Posts: 553

PostPosted: Mon May 12, 2003 2:44 am    Post subject: Reply with quote

vericgar wrote:
From what I understand of the portage system, it shouldn't be to hard to implement this in the ebuild itself. The ebuild can dynamicly generate the SRC_URI

I never could get this to work in practice... and I tried _HARD_ with the phoenix-cvs ebuild a while back to get it to do something sort of like what we're talking about here... Maybe I'm missing something...
Back to top
View user's profile Send private message
jjw
n00b
n00b


Joined: 20 Mar 2003
Posts: 59
Location: Austin, TX, US

PostPosted: Mon May 12, 2003 8:37 am    Post subject: Great package updater available Reply with quote

Hi,
I read your posts and I would like you all to take a look at my project which might be an excellent solution to the problems you mentioned. It's called Deltup, and if it gets merged with Portage it will work automatically, without any extra work when packages are updated! We won't be dependent on the diffs released by the package maintainers either, and finally, YES it does produce correct MD5sums! Please find out more by reading my announcement: http://forums.gentoo.org/viewtopic.php?p=318671. It still might have some bugs... Could someone test this on a 64bit or Big-Endian machine?
---JJW

-------------------------------
Do All for the Glory of God!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum