public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Christian Skarby" <christian@skarby.no>
To: <bain@reaper.org>
Cc: <gentoo-dev@gentoo.org>
Subject: Re: [gentoo-dev] portage question
Date: Wed, 2 Oct 2002 14:23:53 +0200 (CEST)	[thread overview]
Message-ID: <33221.10.0.7.101.1033561433.squirrel@webmail.interhost.no> (raw)
In-Reply-To: <20021002135449.66b52d4c.bain@reaper.org>

> On Wed, 2 Oct 2002 13:53:39 +0200 (CEST)
> "Christian Skarby" <christian@skarby.no> wrote:
>
>> I kind of like the idea of this feature, but AFAIK are diffs most
>> usefull when there are little difference from the source-files we
>> already have. I.e. as soon as all the code is changed a diff-file will
>> include both the old and the new source. If we implement this feature
>> I think it would be nice to put some logic into it so that it can
>> (f.ex. by looking at file-sizes) decide if one should download a patch
>> or two or rather download the full source.
>
> the whole point of a diff/patch file is to make only changes made to the
> source .. not carry the original ..
>
> Henti Smith

:) I think I'll have to be a bit more spesific on this

If we have a source-1.0 that reads
/*
 This is a lovely comment
*/

and then a source-1.1 that reads
/*
 This comment make more sense
*/

a diff would look something like
/*
- This is a lovely comment
+ This comment make more sense
*/

As we see the diff is larger than both the sources, and this will happen
as soon as the all the source is fully replaced. This is actually a worst
case scenario and hence not a good example, nevertheless I believe that
fetching source-1.0.tar.gz and patch-1.1.tar.gz often will result in
downloading more than just source-1.1.tar.gz, thus it will not be cost
effective to get the patch unless one already have the sources that the
patch applies to. Therefor I believe that if we should implement this into
portage it would be nice to have some checks looking at what relevant
source-files we already have, how large the patches are and how large the
full source download is. Then it should be quite easy to consider what
will be the least time consuming download.

Taking in consideration that many (most/all?) gentoo-users keep their
systems up to date at all times with emerge -u world it probably would be
a great ideá just with patches, but I think that new installs and install
of packages with huge rewrites will benefit from having clean full source
downloads. Thus I suggest these checks.

Please arrest me if I am wrong ..

All the best,
Christian





  reply	other threads:[~2002-10-02 12:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-01 23:09 [gentoo-dev] portage question Leon Chiver
2002-10-02  7:22 ` Henti Smith
2002-10-02  7:39   ` Evan Read
2002-10-02  9:02     ` Alexander Gretencord
2002-10-02  9:12       ` Paul de Vrieze
2002-10-02 12:28         ` Toby Dickenson
2002-10-02 12:34         ` Toby Dickenson
2002-10-02 10:06       ` Henti Smith
2002-10-02 11:53         ` Christian Skarby
2002-10-02 11:54           ` Henti Smith
2002-10-02 12:23             ` Christian Skarby [this message]
2002-10-02 12:26               ` Henti Smith
2002-10-02 14:12               ` Alexander Gretencord
2002-10-02 14:11         ` [gentoo-dev] " Leon Chiver
2002-10-03  9:10           ` Paul de Vrieze
  -- strict thread matches above, loose matches on Subject: below --
2001-08-25 15:26 [gentoo-dev] Portage question Christopher Burgess
2001-08-25 15:36 ` Mikael Hallendal
2001-08-25 14:57 Christopher Burgess
2001-08-25 15:06 ` Mikael Hallendal
2001-08-25 15:20   ` Daniel Robbins
2001-08-25 15:32     ` Mikael Hallendal
2001-08-27  8:48 ` Djamil ESSAISSI
2001-01-30 21:23 [gentoo-dev] useradd q Dave Bresson
2001-01-30 21:57 ` Achim Gottinger
2001-01-30 23:14   ` [gentoo-dev] portage question John McCaskey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33221.10.0.7.101.1033561433.squirrel@webmail.interhost.no \
    --to=christian@skarby.no \
    --cc=bain@reaper.org \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox