Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 31946 - portage sequentual patching
Summary: portage sequentual patching
Status: RESOLVED WORKSFORME
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal enhancement
Assignee: Portage team
URL: http://www.gentoo.org/proj/en/glep/gl...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-24 15:16 UTC by Andrew Kirilenko
Modified: 2011-10-30 22:35 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Kirilenko 2003-10-24 15:16:38 UTC
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.
Comment 1 Andrew Kirilenko 2003-10-24 16:14:18 UTC
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.
Comment 2 Andrew Kirilenko 2003-10-25 15:25:15 UTC
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.
Comment 3 SpanKY gentoo-dev 2003-10-25 17:12:26 UTC
if current portage wouldnt support GLEP 9 we could always change how it works
:p
Comment 4 Marius Mauch (RETIRED) gentoo-dev 2003-10-25 17:42:03 UTC
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.
Comment 5 Andrew Kirilenko 2003-10-26 15:09:19 UTC
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.
Comment 6 Marius Mauch (RETIRED) gentoo-dev 2003-10-26 17:26:03 UTC
delup is using binary patches, it patches the .bz2 itself, not the contained
tarball. 
Comment 7 Andrew Kirilenko 2003-10-26 17:31:04 UTC
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.
Comment 8 Marius Mauch (RETIRED) gentoo-dev 2003-10-26 17:42:27 UTC
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.
Comment 9 Andrew Kirilenko 2003-10-29 08:52:08 UTC
Hello!

OK. I'll take a look, but this is hard to beleive :)

Best regards,
Andrew.
Comment 10 Nicholas Jones (RETIRED) gentoo-dev 2003-12-23 23:43:41 UTC
Being resolved elsewhere.