[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian Patch Files

Hi, I was having a discussion about this the other day and I came up with this
proposal, which I would like comments on.

It must be noted that I'm not much of a coder - I'm having problems making a
Python script work as I expect. (Actually, I think this particular problem is
a bug - but I'll see if I can replicate it before pestering :) I am, however,
an optimist. I hope to see this, and my other idea (which I cannot find any
references to in search engines, but I know it's been discussed before) of a
universal package format implemented.

Proposal for Debian Patch Files
Debian packages are upgraded frequently, and I can't help but wonder if it's
necessary for me to download a few megabytes for maintainer's releases. I
think it would be great if I could simply download the differences between
the versions, and save the bandwidth.

	* It should be transparent to debian maintainers
	* Configuration files should be treated specially
	* Not every change will be small enough for a patch,
	* and likewise, many changes are so small it's ridiculous.
	* Users will tweak some files - configuration (handled) and others.

The Patch:
	Should be generated by comparing the extracted contents of the
	old and the new packages. (A package is a single .deb)

	It should also include the md5sums of the files in the old package,
	the configuration files, and the packaging scripts.

	Files in the patch are either patched against the old version,
	replaced entirely, or renamed from an existing file.
	ie. 1) diff file.a file.b > patch.a-b
	    2) file.b > patch.b
	    3) in patch: mv foo.a bar.b

	The final patch, once compressed, should have it's size compared to 
	the new package, and a decision should be made as to whether the
	end justifies the means. (ie. Does the size for the user justify the
	extra space needed by debian mirrors?)

Applying the patch: 
	I feel there is room for two ways here, both with the same outcome.
	Those are to either apply the patch directly, or generate a .deb of
	the new package then install it. The .deb can be generated by using
	a pre-existing .deb (if available), or by collecting all the
	installed files that made up the previous .deb, checking the md5sums,
	applying the patches, and then generating the package from that.

	The package will then go through the normal upgrade procedure - asking
	about replacing configuration files, etc. (Hence including them in
	the patch)

	However, there arises a problem when people are not using an old
	.deb locally, and they modify non-configuration files before
	applying the patch.  Whether or not the file is being patched - it
	is an inconsistency, and should be treated seriously. The user should
	(by default) be required to download the full package and use that.
	However, some people may change a file and, if it's not being
	patched against, keep the change and still apply the patch to the
	rest of the package (also voiding any .deb generated from it).
	There should be a command line / configuration option to prompt the
	user if they wish to continue - or download the whole package and
	install that.

Mail any comments, corrections, and suggestions to
    Robert Thomson <rmt@noosanet.com or c98056651@alinga.newcastle.edu.au>

 Robert Thomson -- Just call me Sir  -=|   UNIX is user friendly.  |=-
  c9805651@alinga.newcastle.edu.au   -=| It's just selective about |=-
        I prefer GNU/Linux	     -=|    who its friends are.   |=-

Reply to: