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

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-31-2008, 03:45 PM
Charles Plessy
 
Default How to cope with patches sanely

Hi Lars, I do not get your point.

If you are concerned that the persons who sent you a package to sponsor
have put malicious code in it, what I guess you will first review is
wether the scripts you have to execute to test the packages are safe. If
you trust the orig.tar.gz tarball and if it has the same md5sum than
upstream, having all of the packager's work under the debian directory
seems to be an advantage to me. Once it is clear that the packager did
not put bad things in the packaging scripts, if inspecting the content
of debian/patches is not your preffered way to work, you can run
'debian/rules patch' safely. And if you are doing a lot of sponsoring,
how likely is it that cdbs, dpatch and quilt are not installed on your
system? In this sponsoring scenario, the benefit of not using a patch
system is mostly to have less lines packaging code to audit.


What I thought we were discussing is that there are too many patch
systems in Debian, and that people who want to modify existing packages
(NMUers, QA team, Security team) can not be requested to learn how to
use them to patch the sources ('debian/rules patch' in 99,99 % of the
cases), or — more seriously — are annoyed that after having modified an
existing package dpkg-buildpackage will fail because 'debian/rules
unpatch' will not work anymore. Shall we conclude that the idea of
automatically applying the patches when the sources are unpacked is
ruled out by the complexity and the side-effect security issues that it
would create ? In the end, checking by hand wether a patch system is
used is not such a big deal: the information is very obvious in most of
the cases, and the standardisation of targets such as 'patch-new', as
proposed earlier, would be much more useful. And thanks to the code
factorisation through makefile includes, these new targest could be
propagated quickly.


I just have read a few more messages in this thread. Maybe it is too
late here, but sorry, I do not understand everything. I have nothing
against change, but if the change is not beneficial to me, and if nobody
helps me to understand, how can I change my tools?. I know I will never
NMU the glibc or the kernel anyway, so I have no incentive or pressure
to study power-tools that will not give me so much benefits in regard to
the investment. However, if somebody could take a video of Pierre's talk
at FOSDEM, I would be grateful. Any howto for dummies would also be
appreciated. Just reading mails saying "your're wrong" with parcellar
inline replies will not make me smarter. In the end, this whole thread
started because powerusers need patch users to stop using patches, not
the reverse. So friends, please come down at our level, and explain us
what to do.


Have a nice day,

--
Charles


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-31-2008, 06:28 PM
Steve Langasek
 
Default How to cope with patches sanely

On Thu, Jan 31, 2008 at 04:38:42PM +0100, Daniel Leidert wrote:
> Am Donnerstag, den 31.01.2008, 16:45 +0200 schrieb Riku Voipio:
> > On Wed, Jan 30, 2008 at 07:38:01PM +0100, Daniel Leidert wrote:
> > > Am Mittwoch, den 30.01.2008, 12:31 -0500 schrieb Joey Hess:
> > > > Because disk space is so much cheaper than your time that I can't even
> > > > find the adjectives to describe how much cheaper it is?

> > > My current workflow is fast enough.

> > ..For your own packages. It's still a burden for you when you NMU other
> > peoples packages or when people NMU your packages.

> The workflow we were discussing (put everything into VCS or not) is IMO
> not related to NMUs. To make a NMU, you get the source via apt-get
> source. I don't think, anybody will use debcheckout or manipulate the
> maintainers VCS. I never saw such a case. Is it common practice for
> someone?

No, but I think it's a *bug* that this is not the common case. If more
packages were maintained in distributed VCS, it would become practical to
consider publishing official "Debian" branches in an organized fashion,
keeping them synced with the maintainer's branch and letting NMUers push
their own changes to the Debian branch so that they're trivially mergeable
by the maintainer with full change history.

This just isn't going to happen as long as svn dominates, because acls on
centralized svn repos are just too coarse-grained. Maintainers (including
me) aren't going to want their package staging areas to be randomly
scribbled on by developers they don't know, which is what opening up an svn
tree to everyone with NMU rights would allow; so that's a conversation we
can't even realistically have without the paradigm shift to DVCS.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-31-2008, 08:21 PM
Ben Finney
 
Default How to cope with patches sanely

Charles Plessy <charles-debian-nospam@plessy.org> writes:

> - In the fist I propose that the 'patch' rule could only be provided
> by snippets such as those of dpatch, quilt, and CDBS, so that there
> is no security risk running this command.

This doesn't do anything to prevent a non-policy-compliant source
package providing arbitrary hostile commands (whether by accident or
malice) in the 'patch' target.

The correct way to avoid that is not to run anything from inside the
source package until the user specifies to do that. Unpacking the
source should *not* require (nor even default to) executing something
from inside that source.

--
"I saw a sign: 'Rest Area 25 Miles'. That's pretty big. Some |
` people must be really tired." —Steven Wright |
_o__) |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-31-2008, 08:25 PM
Ben Finney
 
Default How to cope with patches sanely

Daniel Leidert <daniel.leidert.spam@gmx.net> writes:

> And people should check the VCS history just to get the current
> "patch"?

What is "the current patch"? If you mean the entire set of differences
against the upstream source, I already addressed that: simply generate
a diff between the branches containing upstream source versus
debian-packaged source.

As I pointed out, there are already tools that generate an entire
Debian source package, including 'foo.orig.tar.gz' and 'foo.diff.gz',
in a single step from a given VCS. Evidently what you ask for is
possible, and already indeed implemented such that it is easy.

If you mean something else by "the current patch", please explain
further.

--
"Experience is that marvelous thing that enables you to |
` recognize a mistake when you make it again." —Franklin P. |
_o__) Jones |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-31-2008, 09:52 PM
Andreas Tille
 
Default How to cope with patches sanely

On Thu, 31 Jan 2008, Steve Langasek wrote:


No, but I think it's a *bug* that this is not the common case. If more
packages were maintained in distributed VCS, it would become practical to
consider publishing official "Debian" branches in an organized fashion,
keeping them synced with the maintainer's branch and letting NMUers push
their own changes to the Debian branch so that they're trivially mergeable
by the maintainer with full change history.


Well, I have no personal experience with other VCS than CVS and SVN
but I see some sense behind your arguing and I'm perfectly willing
to enhance my skills if I see some kind of master plan behind it
to enhance Debian in general.


This just isn't going to happen as long as svn dominates, because acls on
centralized svn repos are just too coarse-grained. Maintainers (including
me) aren't going to want their package staging areas to be randomly
scribbled on by developers they don't know, which is what opening up an svn
tree to everyone with NMU rights would allow; so that's a conversation we
can't even realistically have without the paradigm shift to DVCS.


I recently read that Linus spoke about 2000 people who are providing
code to the Linux kernel - so we are talking about the same amount of
people that finally settled down on using git (or were kind of
forced to use git if they wanted to provide code). I'm not sure
whether this is comparable (probably not) but IMHO the best way
would be to start implementing a solution and writing a brain
dead easy doc that enables even dinosaurs like me to apply this
to day to day work without taking hours to gather basic knowledge
how to use the VCS of choice.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-31-2008, 09:52 PM
Andreas Tille
 
Default How to cope with patches sanely

On Thu, 31 Jan 2008, Steve Langasek wrote:


No, but I think it's a *bug* that this is not the common case. If more
packages were maintained in distributed VCS, it would become practical to
consider publishing official "Debian" branches in an organized fashion,
keeping them synced with the maintainer's branch and letting NMUers push
their own changes to the Debian branch so that they're trivially mergeable
by the maintainer with full change history.


Well, I have no personal experience with other VCS than CVS and SVN
but I see some sense behind your arguing and I'm perfectly willing
to enhance my skills if I see some kind of master plan behind it
to enhance Debian in general.


This just isn't going to happen as long as svn dominates, because acls on
centralized svn repos are just too coarse-grained. Maintainers (including
me) aren't going to want their package staging areas to be randomly
scribbled on by developers they don't know, which is what opening up an svn
tree to everyone with NMU rights would allow; so that's a conversation we
can't even realistically have without the paradigm shift to DVCS.


I recently read that Linus spoke about 2000 people who are providing
code to the Linux kernel - so we are talking about the same amount of
people that finally settled down on using git (or were kind of
forced to use git if they wanted to provide code). I'm not sure
whether this is comparable (probably not) but IMHO the best way
would be to start implementing a solution and writing a brain
dead easy doc that enables even dinosaurs like me to apply this
to day to day work without taking hours to gather basic knowledge
how to use the VCS of choice.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 12:42 AM
David Nusinow
 
Default How to cope with patches sanely

Hi buxy,

On Tue, Jan 29, 2008 at 07:44:13AM +0100, Raphael Hertzog wrote:
> I just need a clear concept that I can try to implement.
>
> Some questions/problems:
>
> 1/ it seems that we agree that patches should be applied by default
> during unpack of the source archive. This means that dpkg-source might
> want to know which patches are currently applied (or we could get strange
> results while building the package with patches unapplied)... do we use
> the same format than quilt for that (.pc directory AFAIK)?

My sense is that Ted nailed this one. The thing all the patch systems have
in common is that they have a stack of diffs and a file denoting the order
to apply them. There are variations on the theme (dbs lacks an explicit
series file, and dpatch uses its perverse scripts-as-diffs) but overall
it's consistent. I'd like to see this be the model for whatever dpkg uses.
The file is always kept in the same directory as the patches, so dpkg
should also expect this.

If you want to call the file "series", that'd be sufficient for immediate
quilt use because quilt will generate the .pc directory when used. For the
X packages we don't store the .pc file in the VCS, just the patches and
series file, and it works perfectly. If you name the file something other
than series, it can be symlinked and quilt will work fine.

- David Nusinow


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 12:47 AM
David Nusinow
 
Default How to cope with patches sanely

On Tue, Jan 29, 2008 at 06:52:55PM +0100, sean finney wrote:
> i'd argue that's it's somewhat backwards to expect a patch management system
> like dpatch or quilt to perform this task, and really it should be the
> responsibility of the vcs or vcs-wrapper tools.

I agree entirely.

- David Nusinow


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 07:13 AM
Raphael Hertzog
 
Default How to cope with patches sanely

On Fri, 01 Feb 2008, Ben Finney wrote:
> Daniel Leidert <daniel.leidert.spam@gmx.net> writes:
>
> > And people should check the VCS history just to get the current
> > "patch"?
>
> What is "the current patch"? If you mean the entire set of differences
> against the upstream source, I already addressed that: simply generate
> a diff between the branches containing upstream source versus
> debian-packaged source.
>
> As I pointed out, there are already tools that generate an entire
> Debian source package, including 'foo.orig.tar.gz' and 'foo.diff.gz',
> in a single step from a given VCS. Evidently what you ask for is
> possible, and already indeed implemented such that it is easy.
>
> If you mean something else by "the current patch", please explain
> further.

Imagine an history like this:

- Change behaviour1
- Change behaviour2
- Bugfix in patch to change behaviour1
- Bugfix in patch to change behaviour2

You have two logical patches and a dumb export from the VCS into
debian/patches/ would give 4 patches when you really want only two.

In his own words, "current patch" is the "logical patch".

Cheers,
--
Raphal Hertzog

Le best-seller franais mis jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2008, 07:35 AM
Ben Finney
 
Default How to cope with patches sanely

Raphael, please follow the Debian Mailing List code of conduct
<URL:http://www.debian.org/MailingLists#codeofconduct>; in particular,
don't send individual copies of list messages unless specifically
requested.

Raphael Hertzog <hertzog@debian.org> writes:

> Imagine an history like this:
>
> - Change behaviour1
> - Change behaviour2
> - Bugfix in patch to change behaviour1
> - Bugfix in patch to change behaviour2
>
> You have two logical patches and a dumb export from the VCS into
> debian/patches/ would give 4 patches when you really want only two.

In a VCS with good merging support (most DVCSes fit this description,
Subversion does not), those "logical patches" can be maintained as
"feature branches".

Essentially, any set of changes that is more than "add this change and
let it be absorbed into the stream of changes" merits branching the
development tree to maintain that feature. Into that feature branch go
any commits that are related logically to the feature; anything else
goes into other branches.

Any time you want to find how feature-branch-A differs from the
development branch, that's a simple diff operation between the two
branches (optionally specifying which revision of each you're
interested in comparing). Merges between the two will show up as
single revisions in each branch, so the changes in feature-branch-A
will show exactly the history of feature A.

Any time the changes in feature-branch-A are at a point where they
need to be included in the main development branch, simply merge them
in.

The important thing that enables this workflow is *easy merging*
between arbitrary branches that share a common ancestor. Again, this
rules CVS and Subversion out. (Some, like git, allow merging
*anywhere*, but that's not necessary for this to work well.)

--
"I have had a perfectly wonderful evening, but this wasn't it." |
` -- Groucho Marx |
_o__) |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 10:26 AM.

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