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 02-01-2008, 08:18 AM
Josselin Mouette
 
Default How to cope with patches sanely

Le jeudi 31 janvier 2008 √* 11:28 -0800, Steve Langasek a √©crit :
> 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.

Really? GNOME has been doing that for years, and I don’t think they are
drowning under unwanted commits by developers not following policies.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 02-01-2008, 08:42 AM
Lars Wirzenius
 
Default How to cope with patches sanely

On pe, 2008-02-01 at 01:45 +0900, Charles Plessy wrote:
> 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.

At the moment, I can unpack a source package and then review it before I
run anything. You propose to make things more complicated by having to
review things before unpacking. I find that to be an unwanted,
unnecessary, and _dangerous_ complication.

> 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 ?

That is a highly premature conclusion. We can create ways in which
patches are applied by dpkg-source directly, for example, instead of
having to run code from the package. That's the point of my
participation in this sub-thread: to stop the _wrong_ way of
implementing this.

See David Nusinow's e-mail[1] as an example of an outline for how this
can be done sanely. (He refers to Ted Tso's e-mail, and I think it's
[2].)

[1] http://lists.debian.org/debian-devel/2008/02/msg00003.html
[2] http://lists.debian.org/debian-devel/2008/01/msg01008.html



--
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, 08:45 AM
Raphael Hertzog
 
Default How to cope with patches sanely

On Fri, 01 Feb 2008, Ben Finney wrote:
> 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.

If you were using mutt and a right configuration, you would have
an appropriate Mail-Followup-To and those mistakes wouldn't happen... (I
so hate those discussions and remarks about code of conduct for one copy
more of a mail).

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

Thank you, I know a DVCS can be used. However it's not that easy, one
feature branch might rely on another one and then you have to keep that
ancestry information to be able to generate the diffs properly (and in the
right order).

And as explained somewhere else in this thread, this doesn't scale very
well with dozens of patches.

With git I'd use a "debian-patches" branch that I would rebase on the
upstream branch regularly and would edit history of changes as needed so
that one commit generates one file in debian/patches/.

Anyway, I didn't want to discuss this, but just point out what Daniel was
saying.

Cheers,
--
RaphaŽl Hertzog

Le best-seller franÁais 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, 09:10 AM
Josselin Mouette
 
Default How to cope with patches sanely

Le vendredi 01 f√©vrier 2008 √* 10:45 +0100, Raphael Hertzog a √©crit :
> If you were using mutt and a right configuration, you would have
> an appropriate Mail-Followup-To and those mistakes wouldn't happen...

Mail-Followup-To is not a standard of any kind. Only a handful of
mailers understand it and I don’t think this is going to change.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 02-01-2008, 10:59 AM
Ben Finney
 
Default How to cope with patches sanely

Raphael Hertzog <hertzog@debian.org> writes:

> On Fri, 01 Feb 2008, Ben Finney wrote:
> > 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.
>
> If you were using mutt [...]

I'm not. Please follow the code of conduct regardless.

--
"For of those to whom much is given, much is required." -- |
` John F. Kennedy |
_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 02-01-2008, 11:33 AM
Daniel Leidert
 
Default How to cope with patches sanely

Am Freitag, den 01.02.2008, 08:25 +1100 schrieb Ben Finney:
> 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"?

The current specific/logical patch for one issue.

> 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.

I did not refer to generate the .diff.gz. I know, this can easily be
done by diff-ing two branches.

What I mean is: Say you have addressed 5 different issues in the code. I
still think it is easier to understand, if 5 separate patches are
provided instead of one. And tracking each of them be checking commits
for the initial fix and changes done later to update the fix is IMHO not
as easy as simply providing a separate patch. As long as you maintain
the package alone, you probably do not have advantages of using separate
patches. But say e.g. a co-maintainer offers help or you do
collaborative maintenance in general. Then I think, it is much easier to
separate fixes into logical patches. And IMHO this cannot be done by
just using "good" commit messages.

> 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.

What I ask for is already possible and implemented: quilt and dpatch
exist. But I cannot agree to your opinion, that "[..] commits [..] at
the same level of granularity (or finer) [..]" offer the same
functionality and advantages. This is IMO not a valuable replacement for
separated patches, because of the reasons I tried to point out in my
last mail.

I read your answer to Raphael, where you point to so called "feature
branches". This leads to the question, if people should be forced to use
a special VCS (which is already discussed somewhere else in the thread),
whereas creating Debian packages never relayed on the usage of a VCS.

To be honest, your workflow is different to mine. I would need to
examine your way and compare it to mine. All I can say is, that I'm
pretty satisfied with my workflow and I'm sure, you claim the same for
your solution.

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

HTH
Regards, Daniel


--
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, 02:29 PM
"Kumar Appaiah"
 
Default How to cope with patches sanely

On 01/02/2008, Raphael Hertzog wrote:
> With git I'd use a "debian-patches" branch that I would rebase on the
> upstream branch regularly and would edit history of changes as needed so
> that one commit generates one file in debian/patches/.

Dear Raphael,

Is this what you mean?

- Have a branch upstream, and upstream-patched
- Make upstream stay in sync with the upstream tarball. Merge it with
debian-patches
- Use the differences between these branches to generate
debian/patches, which can be wrapped around
quilt/dpatch/simple-patchsys?

Thanks.

Kumar
--
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036


--
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, 04:06 PM
Raphael Hertzog
 
Default How to cope with patches sanely

Hi,

On Fri, 01 Feb 2008, Kumar Appaiah wrote:
> On 01/02/2008, Raphael Hertzog wrote:
> > With git I'd use a "debian-patches" branch that I would rebase on the
> > upstream branch regularly and would edit history of changes as needed so
> > that one commit generates one file in debian/patches/.
>
> Dear Raphael,
>
> Is this what you mean?
>
> - Have a branch upstream, and upstream-patched
> - Make upstream stay in sync with the upstream tarball. Merge it with
> debian-patches

No, I said "rebase" and not merge.
See http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

(Note that this means that nobody should derive from upstream-patched as
the branch is regularly rewritten and one can't branch and later merge
from it)

> - Use the differences between these branches to generate
> debian/patches

Yes. git rev-list upstream..upstream-patched would give a list of commit
to use to generate the debian/patches/

Cheers,
--
RaphaŽl Hertzog

Le best-seller franÁais 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-02-2008, 05:36 AM
martin f krafft
 
Default How to cope with patches sanely

also sprach Pierre Habouzit <madcoder@debian.org> [2008.01.27.0323 +1100]:
> For example when you need different series of patches per
> architecture (the libc e.g. has specific hurd patches).

Wouldn't this be handled better with preprocessor #ifdefs? I'd say
it would make the code clearer and more maintainable. But then
again, I have none (read: zero) experience with this sort of
challenge.

--
martin | http://madduck.net/ | http://two.sentenc.es/

"life moves pretty fast. if you don't stop and look around once in
a while, you could miss it."
-- ferris bueller

spamtraps: madduck.bogus@madduck.net
 
Old 02-02-2008, 05:38 AM
martin f krafft
 
Default How to cope with patches sanely

also sprach Mike Hommey <mh@glandium.org> [2008.01.27.0551 +1100]:
> On Sat, Jan 26, 2008 at 07:10:42PM +0100, Pierre Habouzit wrote:
> > On Sat, Jan 26, 2008 at 04:35:24PM +0000, Mike Hommey wrote:
> > > On Sat, Jan 26, 2008 at 05:23:16PM +0100, Pierre Habouzit wrote:
> > > > On Sat, Jan 26, 2008 at 03:44:20PM +0000, Andreas Metzler wrote:
> > > > > Josselin Mouette <joss@debian.org> wrote:

... dudes...

> FWIW, dpatch has a patch edition facility (and I think it's been
> there since near the beginning), but it was a PITA to use on big
> source trees. I don't know if that changed.

It doesn't merge. It sucks.

--
.'`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems

what do you mean, it's not packaged in debian?
 

Thread Tools




All times are GMT. The time now is 01:12 PM.

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