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 dpkg

 
 
LinkBack Thread Tools
 
Old 09-05-2008, 11:56 AM
Raphael Hertzog
 
Default Proposal: debian/include

Hi Morten,

you mail has not much to do on debian-policy. It rather concerns dpkg and
dpkg-dev and as such I'm taking the discussion to
debian-dpkg@lists.debian.org.

On Fri, 05 Sep 2008, Morten Kjeldgaard wrote:
> In the olden days (OK, I am guessing here) people used to hack away at
> upstream's source directory, trusting that all changes were recorded in
> the *.diff.gz file. The trend is now to have only debian/ present in
> *.diff.gz, and with all the packager's modifcations in debian/patches/,
> controlled by dpatch, quilt or some other system.
>
> I propose that this trend is made more explicit,

The trend will already be made more explicit when we swicth to the new
source package format "3.0 (quilt)". See dpkg-source's manual page for more
details.

> by adding to policy an optional file, debian/include, that explicitly
> lists what files/ directories outside of debian/ should be included in
> *.diff.gz. The format of that file should allow for comments explaining
> why those particular parts are needed in the diff.gz.

This can already be done at run-time with the -i option of
dpkg-source. In the future, I'll probably give the possibility to
provide default command-line options in the source package within the file
debian/source/build-options but I haven't implemented this yet.

> Why is this needed? Personally, I have met several situations where I
> -- intentionally or not -- have dropped temporary files, scripts, notes
> to myself, copies of source files, etc. in source directories which i
> later to my dismay discover end up in the .diff.gz file.
>
> Also, if you for some reason need to re-run the GNU autotools, the whole
> directory tree will contain Makefile.in's aclocal.m4 or other files
> generated by that system, that you meticuously have to remove in the
> clean target of debian/rules in order for the source package to build
> properly and cleanly.
>
> The existence of an empty debian/include file -- or perhaps the absense
> of the file -- would signal to the build system to ignore everything
> outside of debian/ for inclusion in the *.diff.gz. If, for some reason,
> you really want changes to the source tree, just name those files or
> directories in debian/include.

With the new format, if you have local changes, they will be integrated in the
quilt serie as a new patch and the patch will be automatically named
by dpkg-source. lintian will probably (one day) warn about such patches
because when you modify the upstream sources, you must have a good reason
to do it and thus you should be able to give a proper name to the patch
and describe it instead of just letting dpkg-source record the change.

Feel free to give a try to the new format and see if there are
other things that can be improved to resolve your concerns.

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-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-06-2008, 04:23 PM
Morten Kjeldgaard
 
Default Proposal: debian/include

On 05/09/2008, at 13.56, Raphael Hertzog wrote:


by adding to policy an optional file, debian/include, that explicitly
lists what files/ directories outside of debian/ should be included
in
*.diff.gz. The format of that file should allow for comments
explaining

why those particular parts are needed in the diff.gz.


This can already be done at run-time with the -i option of
dpkg-source. In the future, I'll probably give the possibility to
provide default command-line options in the source package within
the file

debian/source/build-options but I haven't implemented this yet.


As far as I know, the -i option tells dpkg-source to ignore something,
but what I propose is in fact the opposite... a list of what you want.
Furthermore, the -i option only works for the person issuing the
command. If someone else attempts to create a source package, that
person may not use the -i switch. With a list in debian/include, it
wouldn't matter how you invoke the tools to build the packge.


With the new format, if you have local changes, they will be
integrated in the

quilt serie as a new patch and the patch will be automatically named
by dpkg-source. lintian will probably (one day) warn about such
patches
because when you modify the upstream sources, you must have a good
reason
to do it and thus you should be able to give a proper name to the
patch

and describe it instead of just letting dpkg-source record the change.


I appreciate that this can be a useful feature, but it does not really
change the situation where you end up with a bunch of undesired
patches because of things you have done to the source tree. It only
changes _where_ those patches appear, but you still need to fix the
source tree so they are not built.


The advantage of the debian/include file is that the packager is
completely in control of what goes into diff.gz (or quilt patches, for
that matter), namely nothing if the file is empty. And this
information would remain with the source package.



Feel free to give a try to the new format and see if there are
other things that can be improved to resolve your concerns.


I am certainly interested in learning more about the new format!

Cheers,
Morten



--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 09:12 AM
Goswin von Brederlow
 
Default Proposal: debian/include

Morten Kjeldgaard <mok@bioxray.au.dk> writes:

> On 05/09/2008, at 13.56, Raphael Hertzog wrote:
>
>>> by adding to policy an optional file, debian/include, that explicitly
>>> lists what files/ directories outside of debian/ should be included
>>> in
>>> *.diff.gz. The format of that file should allow for comments
>>> explaining
>>> why those particular parts are needed in the diff.gz.
>>
>> This can already be done at run-time with the -i option of
>> dpkg-source. In the future, I'll probably give the possibility to
>> provide default command-line options in the source package within
>> the file
>> debian/source/build-options but I haven't implemented this yet.
>
> As far as I know, the -i option tells dpkg-source to ignore something,
> but what I propose is in fact the opposite... a list of what you want.
> Furthermore, the -i option only works for the person issuing the
> command. If someone else attempts to create a source package, that
> person may not use the -i switch. With a list in debian/include, it
> wouldn't matter how you invoke the tools to build the packge.
>
>> With the new format, if you have local changes, they will be
>> integrated in the
>> quilt serie as a new patch and the patch will be automatically named
>> by dpkg-source. lintian will probably (one day) warn about such
>> patches
>> because when you modify the upstream sources, you must have a good
>> reason
>> to do it and thus you should be able to give a proper name to the
>> patch
>> and describe it instead of just letting dpkg-source record the change.
>
> I appreciate that this can be a useful feature, but it does not really
> change the situation where you end up with a bunch of undesired
> patches because of things you have done to the source tree. It only
> changes _where_ those patches appear, but you still need to fix the
> source tree so they are not built.
>
> The advantage of the debian/include file is that the packager is
> completely in control of what goes into diff.gz (or quilt patches, for
> that matter), namely nothing if the file is empty. And this
> information would remain with the source package.

You are attcking this from the wrong side.

By specifying what should be included you make it verry easy to forget
stuff.

What you should do is specify what should be excluded. That way new
stuff will automatically be included and only stuff you know to be bad
is left out.

>> Feel free to give a try to the new format and see if there are
>> other things that can be improved to resolve your concerns.
>
> I am certainly interested in learning more about the new format!
>
> Cheers,
> Morten

There are only 2 reasons to not have something in the patch
automatically:

1) RCS infos that you have locally but are not to be part of the Debian
source (are not part of the source at all).

2) You do not clean up properly in debian/rules clean.

For 1 it would be nice to specify a default -i/-I option for
dpkg-source inside the debian source (as Raphael described). But 2
should be fixed to clean up properly and not worked around by
including/excluding.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-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 12:55 AM.

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