FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 01-12-2008, 07:41 PM
Evan
 
Default Patching

Currently, when a minor patch is uploaded to the update mirrors, Ubuntu users must download the entire deb package again. When it is a big package (say OpenOffice.org) and it is a small patch of just a few lines of code, this can get somewhat ridiculous.
(Update size generally < 50MB)

When Windows/OSX users recieve a patch, they get it in the form of an execuable (.msi IIRC) which modifies the executable directly. While this method saves considerable space over our current method, it would impose a major strain on the package maintainers to create an updater for every version. (Update size generally < 5MB)


Any change in this area is far too complex for a LTS, however for 8.10 we have the opportunity to be innovative and create a new patching system better than that being used by the competition:

Write a new program that is generically designed to modify any binary according to parameters it is passed. Write a second program that compares two .deb packages and outputs the parameters the first program would need to get from version 1 to version 2. (Update size generally < 1MB)


An example would work like this:

A new package called abc is added to the repos at version 1.Bob installs abc from synaptic.The creator of abc writes a patch, and packages abc version 1.1 the way they do now.When uploaded, the server that handles uploads compares version
1.1 with version 1 and outputs an update file (some sort of xml format?)Bob checks for updates, finds that abc has a new version, and downloads the update, which is only the xml update fileThe installer passes the new binary-update program the xml file it downloaded, and the abc binary is updated with the patch.
Pros:
No extra work for package maintainers.Extremely tiny updates.Cons:
The method I described can't handle updates to non-binary files (help files, icons, etc.) This would have to be integrated somehow.
The framework would take considerable effort by the devs to set up.Overall, I think this new method is definitely a huge step forward. We are currently behind MS and Apple in this regard, and we have the opportunity not just to catch up, but to pass them. It would take a lot of work to get right, but it would be worth it.


Evan

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
 
Old 01-12-2008, 07:45 PM
"Bryan Haskins"
 
Default Patching

Delta-Debs are already developing, it's just not something we wanted to do yet last I knew. It adds a ton more complication server end.

On Jan 12, 2008 3:41 PM, Evan <
eapache@gmail.com> wrote:
Currently, when a minor patch is uploaded to the update mirrors, Ubuntu users must download the entire deb package again. When it is a big package (say
OpenOffice.org) and it is a small patch of just a few lines of code, this can get somewhat ridiculous.
(Update size generally < 50MB)

When Windows/OSX users recieve a patch, they get it in the form of an execuable (.msi IIRC) which modifies the executable directly. While this method saves considerable space over our current method, it would impose a major strain on the package maintainers to create an updater for every version. (Update size generally < 5MB)


Any change in this area is far too complex for a LTS, however for 8.10 we have the opportunity to be innovative and create a new patching system better than that being used by the competition:

Write a new program that is generically designed to modify any binary according to parameters it is passed. Write a second program that compares two .deb packages and outputs the parameters the first program would need to get from version 1 to version 2. (Update size generally < 1MB)


An example would work like this:

A new package called abc is added to the repos at version 1.Bob installs abc from synaptic.The creator of abc writes a patch, and packages abc version 1.1 the way they do now.When uploaded, the server that handles uploads compares version
1.1 with version 1 and outputs an update file (some sort of xml format?)Bob checks for updates, finds that abc has a new version, and downloads the update, which is only the xml update fileThe installer passes the new binary-update program the xml file it downloaded, and the abc binary is updated with the patch.
Pros:
No extra work for package maintainers.Extremely tiny updates.Cons:
The method I described can't handle updates to non-binary files (help files, icons, etc.) This would have to be integrated somehow.
The framework would take considerable effort by the devs to set up.Overall, I think this new method is definitely a huge step forward. We are currently behind MS and Apple in this regard, and we have the opportunity not just to catch up, but to pass them. It would take a lot of work to get right, but it would be worth it.


Evan


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss



--
Cheers,
Bryan

Freenode: Toxicity999
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
 
Old 01-12-2008, 10:16 PM
"Aaron Whitehouse"
 
Default Patching

On 13/01/2008, Evan <eapache@gmail.com> wrote:
> Any change in this area is far too complex for a LTS, however for 8.10 we
> have the opportunity to be innovative and create a new patching system
> better than that being used by the competition:

An interesting discussion of these kinds of changes can be found here:
https://launchpad.net/ubuntu/+spec/succinct
https://wiki.ubuntu.com/apt-sync (the "summary" section contains links
to other patching ideas and outlines problems with taking a patch
approach)
https://blueprints.launchpad.net/ubuntu/+spec/apt-sync

And somebody has made the delta suggestion here:
https://blueprints.launchpad.net/ubuntu/+spec/apt-deltas

For me (with several Ubuntu machines on the same network), the work
being undertaken under this head -
https://blueprints.launchpad.net/ubuntu/+spec/apt-avahi - would have a
bigger impact on my bandwidth.

Aaron

--
FSF Associate Member: 5632
http://www.fsf.org

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
 
Old 01-13-2008, 12:45 AM
"Bryan Quigley"
 
Default Patching

I believe the best solution to these problems is the use of debtorrent (http://debtorrent.alioth.debian.org/)
Which is currently in hardy (although might not actually fully work yet).* Both solutions mentioned can be implemented eventually through the use of torrents.


I don't believe either is implemented yet:
Torrents check files in pieces so if some of the pieces have not changed they won't need to be redownloaded.
Some torrent programs are currently trying to find local network hosts first, before getting files from outside.


In my opinion it makes more sense to let the protocol worry about these things then include them in apt.*
Thanks,
Bryan



On Jan 12, 2008 6:16 PM, Aaron Whitehouse <
lists@whitehouse.org.nz> wrote:

On 13/01/2008, Evan <eapache@gmail.com> wrote:
> Any change in this area is far too complex for a LTS, however for 8.10 we
> have the opportunity to be innovative and create a new patching system

> better than that being used by the competition:

An interesting discussion of these kinds of changes can be found here:
https://launchpad.net/ubuntu/+spec/succinct

https://wiki.ubuntu.com/apt-sync (the "summary" section contains links
to other patching ideas and outlines problems with taking a patch

approach)
https://blueprints.launchpad.net/ubuntu/+spec/apt-sync

And somebody has made the delta suggestion here:

https://blueprints.launchpad.net/ubuntu/+spec/apt-deltas

For me (with several Ubuntu machines on the same network), the work
being undertaken under this head -

https://blueprints.launchpad.net/ubuntu/+spec/apt-avahi - would have a
bigger impact on my bandwidth.

Aaron

--
FSF Associate Member: 5632
http://www.fsf.org


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
 
Old 01-13-2008, 04:51 PM
Markus Hitter
 
Default Patching

Am 13.01.2008 um 02:45 schrieb Bryan Quigley:

> I don't believe either is implemented yet:
> Torrents check files in pieces so if some of the pieces have not
> changed they won't need to be redownloaded.

While this sounds good in theory, it rarely works in practice: Remove
a byte from the first chunk and all other chunks will point to a
different range of the remaining file, resulting in a different hash
and re-download of all chunks.


Am 12.01.2008 um 21:41 schrieb Evan:

> Cons:
>
> - The method I described can't handle updates to non-binary files
> (help files, icons, etc.) This would have to be integrated somehow.

I can't follow you here as _any_ file can be handled as binary. Like
Subversion does, for example.


IMHO, a successful patch mechanism would store the complete package
on both ends. Just for downloading, a server could offer a patch
against an already downloaded, similar package to make the download
faster/using less bandwidth. A good patching algorithm isn't trivial
and could include extracting and re-assembling the package on the
client side.


Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/





--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
 
Old 03-10-2010, 10:01 PM
Paul Mattal
 
Default patching

I wanted to ask about how others treat patching.

My understanding of our patching philosophy is:

1) Don't patch if doing so makes us un-vanilla. Users familiar with
the standard behavior of software should be able to rely on our
packaged versions to behave the same way.


2) If there's some major roadblock (crash, hang, data loss, chronic
incompatibility), apply a reasonable patch as a workaround, as long
as this kind of patch for this kind of problem has not been rejected
upstream. Report the bug and patch upstream, and remove the patch
from our package when upstream integrates a fix.


3) We don't maintain upstream software; we should not do a lot of
work to patch unmaintained software.


Is this a good summary? Or do others have differing views on some of
this? Things to add?


- P
 
Old 03-10-2010, 10:13 PM
Andrea Scarpino
 
Default patching

On Thursday 11 March 2010 00:01:58 Paul Mattal wrote:
> My understanding of our patching philosophy is:
>
> 1) Don't patch if doing so makes us un-vanilla. Users familiar with
> the standard behavior of software should be able to rely on our
> packaged versions to behave the same way.
>
> 2) If there's some major roadblock (crash, hang, data loss, chronic
> incompatibility), apply a reasonable patch as a workaround, as long
> as this kind of patch for this kind of problem has not been rejected
> upstream. Report the bug and patch upstream, and remove the patch
> from our package when upstream integrates a fix.
>
> 3) We don't maintain upstream software; we should not do a lot of
> work to patch unmaintained software.
I am totally agree with these rules.
I don't like to patch software to provides this or that feature, but we need
to patch a software that does not work due a bug fixed upstream.

People can edit and rebuild packages using ABS and/or AUR.

"Arch was made to work with you, not for you" [A. Griffin]

--
Andrea
 
Old 03-10-2010, 10:13 PM
Allan McRae
 
Default patching

On 11/03/10 09:01, Paul Mattal wrote:

I wanted to ask about how others treat patching.

My understanding of our patching philosophy is:

1) Don't patch if doing so makes us un-vanilla. Users familiar with the
standard behavior of software should be able to rely on our packaged
versions to behave the same way.

2) If there's some major roadblock (crash, hang, data loss, chronic
incompatibility), apply a reasonable patch as a workaround, as long as
this kind of patch for this kind of problem has not been rejected
upstream. Report the bug and patch upstream, and remove the patch from
our package when upstream integrates a fix.

3) We don't maintain upstream software; we should not do a lot of work
to patch unmaintained software.

Is this a good summary? Or do others have differing views on some of
this? Things to add?



http://wiki.archlinux.org/index.php/DeveloperWiki:Patching
 
Old 03-10-2010, 11:21 PM
Paul Mattal
 
Default patching

On 03/10/2010 06:13 PM, Allan McRae wrote:

On 11/03/10 09:01, Paul Mattal wrote:

I wanted to ask about how others treat patching.

My understanding of our patching philosophy is:

1) Don't patch if doing so makes us un-vanilla. Users familiar with the
standard behavior of software should be able to rely on our packaged
versions to behave the same way.

2) If there's some major roadblock (crash, hang, data loss, chronic
incompatibility), apply a reasonable patch as a workaround, as long as
this kind of patch for this kind of problem has not been rejected
upstream. Report the bug and patch upstream, and remove the patch from
our package when upstream integrates a fix.

3) We don't maintain upstream software; we should not do a lot of work
to patch unmaintained software.

Is this a good summary? Or do others have differing views on some of
this? Things to add?



http://wiki.archlinux.org/index.php/DeveloperWiki:Patching


Hah! I actually searched for such a wiki page but did not find it. It
sounds like it's very much in line with what I wrote, but spells out a
few particular cases, which is very helpful.


I was mostly concerned with determining that folks did not think we
needed to wait for upstream to approve before patching for big issues.
We act fast on big issue patches with our best judgment, and then accept
upstream's judgment once it is established.


- P
 
Old 03-10-2010, 11:44 PM
Allan McRae
 
Default patching

On 11/03/10 10:21, Paul Mattal wrote:

On 03/10/2010 06:13 PM, Allan McRae wrote:

On 11/03/10 09:01, Paul Mattal wrote:

I wanted to ask about how others treat patching.

My understanding of our patching philosophy is:

1) Don't patch if doing so makes us un-vanilla. Users familiar with the
standard behavior of software should be able to rely on our packaged
versions to behave the same way.

2) If there's some major roadblock (crash, hang, data loss, chronic
incompatibility), apply a reasonable patch as a workaround, as long as
this kind of patch for this kind of problem has not been rejected
upstream. Report the bug and patch upstream, and remove the patch from
our package when upstream integrates a fix.

3) We don't maintain upstream software; we should not do a lot of work
to patch unmaintained software.

Is this a good summary? Or do others have differing views on some of
this? Things to add?



http://wiki.archlinux.org/index.php/DeveloperWiki:Patching


Hah! I actually searched for such a wiki page but did not find it. It
sounds like it's very much in line with what I wrote, but spells out a
few particular cases, which is very helpful.

I was mostly concerned with determining that folks did not think we
needed to wait for upstream to approve before patching for big issues.
We act fast on big issue patches with our best judgment, and then accept
upstream's judgment once it is established.


I think that falls into this category:
When a *major feature* doesn't work in the app, bug fix patches are allowed.

As long as the patch goes upstream, we can monitor its progress and make
any changes upstream decides need be done.


I was thinking that perhaps we should encourage all patches to have a
header. e.g. LFS does this:


Submitted By:
Date:
Initial Package Version:
Upstream Status:
Origin:
Description:

Debian has something similar. That way we could keep track of why
patches are being used.


Allan
 

Thread Tools




All times are GMT. The time now is 07:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org