| Summary: | portage sequentual patching | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Andrew Kirilenko <andrew.kirilenko> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | enhancement | CC: | radek |
| Priority: | Normal | ||
| Version: | 2.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.gentoo.org/proj/en/glep/glep-0009.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Hello! Hm. Interesting. I would like to play with GLEP... Thanks. PS. I ahve tried googling before posting and haven't found GLEP. Strange. Best regards, Andrew. Hello! Hm. I don't think that GLEP will solve the problem for one somple reason: digest files. I'd propose to have patch (or seqpatch or whatever) flag in make.conf and if ebuild will support patching it'll look for this flag iand fetch the base version of package (in case of development-sources it can be linux-2.6.0-test1.tar.bz2) and all required patches. Otherwise it'll works as it works now. This will be highly compatible eith current poratge realisation (and especially digests). PS. Everything here is IMHO. Best regards, Andrew. if current portage wouldnt support GLEP 9 we could always change how it works :p AFAIK deltup generates identic tarballs, so digests won't be a problem. The major reason it's not officially implemented yet is that we don't have any detailed information about how much additional discspace the patches would need on the mirrors, this information is needed for any kind of patch system. Hello!
>AFAIK deltup generates identic tarballs, so digests won't be a problem.
Really? How it can generate IDENTICAL tarbals?
Take a look:
-->
iced iced $ mkdir foo
iced iced $ touch foo/bar
iced iced $ tar cvf foo.tar foo
foo/
foo/bar
iced iced $ bzip2 foo.tar
iced iced $ md5sum foo.tar.bz2
f87f63fb9b07302884ac3bbb5408701c foo.tar.bz2
iced iced $ touch foo/bar
iced iced $ rm foo.tar.bz2
iced iced $ tar cvf foo.tar foo
foo/
foo/bar
iced iced $ bzip2 foo.tar
iced iced $ md5sum foo.tar.bz2
13b5d8b61028c4e9cc1f9ba0469f9788 foo.tar.bz2
<--
What's different? Timestamps of the files! And you simply can't set all timestamps
as in the original archive (or you will need script which will set all timestamps
before patching on the user side - not good at all).
Another thing, is that you don't know which swiches are used to generate
original tarballs (e.g. `bzip2 foo.tar` or `bzip2 -9 foo.tar`).
So, once again, this idea simply won't work.
Best regards,
Andrew.
delup is using binary patches, it patches the .bz2 itself, not the contained tarball. Hello! Binary patches???? Really? Can't beleive this. Size of binarfy pacth will be about three times bigger than of source patch. And where is advantage for the dialup users here? Best regards, Andrew. IIRC jjw claimed that the patch from openoffice-1.0.2 to 1.0.3 was ~170 KB, I only tested it once and it worked fine. I don't know HOW it works exactly, so if you need more details please test it yourself, read the sourcecode or ask jjw or ferringb (on IRC or the forums), they know this stuff far better than me. But don't say it doesn't work unless you have some facts. Hello! OK. I'll take a look, but this is hard to beleive :) Best regards, Andrew. Being resolved elsewhere. |
Hello! It's totally boring to download completly new tarball for the new package version. Even in winblows you can download just a patch instead of complete installation. I can't say, that's very bad for small packages (like wget or portage itself), but it's really bad for big ones (such as kernel or mozilla). And it's nightmare for dialup users. As for myself I'm doing following job (let's take development-sources-beta8 for example). --> .... BKV="2.6.0-test6" # this is base version, which will be patched # patch files from BKV to PKV .... PATCH_URI="${PATCH_URI} mirror://kernel/linux/kernel/v2.6/patch-2.6.0-test7.bz2 mirror://kernel/linux/kernel/v2.6/patch-2.6.0-test8.bz2" SRC_URI="mirror://kernel/linux/kernel/v2.6/linux-${BKV}.tar.bz2 ${PATCH_URI} ${GPATCH_URI}" .... src_unpack() { cd ${WORKDIR} unpack linux-${OKV}.tar.bz2 # rename to current version mv linux-${BKV} linux-${PKV} # unpack version patches unpack patch-2.6.0-test{7,8}.bz2 # apply version patches cd ${S} epatch ${WORKDIR}/patch-2.6.0-test7 epatch ${WORKDIR}/patch-2.6.0-test8 # and rm them rm -f ${WORKDIR}/patch-2.6.0-test{7,8} .... } <--- Of course, it's not elegant not useful solution (I need do this manually each time). It'll be better to create some uniform way to do this (maybe via eclass?) and get major big packages (kernel, mozilla, xfree, openoffice, ...) use it. Also, my distfiles dir looks like a trash. Maybe it'll be better to store fetched files in the separate (package beased) dir? Best regards, Andrew.