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 06-04-2011, 12:01 PM
Jonas Smedegaard
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

Hi fellow hackers,

I have noticed several times package changes like the following (from
cairomm entering testing today):

* debian/control:
- Drop build dependencies on doxygen and graphviz, since upstream
now ships the generated documentation


Feels wrong to me to redistribute when e.g. html files clearly are not
the preferred form of editing for upstream.

I also avoid redistributing PDF files provided by upstream - and in some
cases even strip it from redistributed source, as it is a binary thingy
which potentially may contain non-free code.

On the other hand, I often include graphics files even if those also are
binary and may potentially contain non-free code (although less likely).


Seems inconsistent to me.

Do we have some consensus on what is ok to redistribute as-is and what
not?

Or can some of you enlighten me with your personal reasoning for your
own packaging style?


Regards,

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
 
Old 06-04-2011, 12:10 PM
Gergely Nagy
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

Jonas Smedegaard <dr@jones.dk> writes:

> I have noticed several times package changes like the following (from
> cairomm entering testing today):
>
> * debian/control:
> - Drop build dependencies on doxygen and graphviz, since upstream
> now ships the generated documentation
>
>
> Feels wrong to me to redistribute when e.g. html files clearly are not
> the preferred form of editing for upstream.

To me, that doesn't sound all that troubling: we do use other generated
files that upstream ships more often than not: configure, Makefile.ins -
and so on. Though, those are rarely shipped in the binary package, but
still: we do not build-depend on the tools that generate these.

Technically, upstream could do anything in those files, write them by
hand instead of generating from configure.ac, and include that in the
distributed tarball, potentially under a non-free license.

In any case: even if upstream shipts generated content, as long as the
source is shipped aswell, all is fine and well, in my opinion. The
_source_ needs to be in the preferred form of modification. If it
contains generated files aswell, that doesn't matter all that much: the
source is still there. You just don't have to use it, if the result
would be the same anyway.

> Or can some of you enlighten me with your personal reasoning for your
> own packaging style?

My personal preference is to trust upstream to not be a moron, and if he
makes my job easier, cutting build-dependencies down, I'm all for it.

(Provided that said action does not cause unwanted side effects, like
the documentation being out of date, because upstream forgot to
regenerate them before distribution - but that falls under the "upstream
to not be a moron" above

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipslg5lg.fsf@luthien.mhp">http://lists.debian.org/87ipslg5lg.fsf@luthien.mhp
 
Old 06-04-2011, 12:22 PM
Benjamin Drung
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

Am Samstag, den 04.06.2011, 14:10 +0200 schrieb Gergely Nagy:
> Jonas Smedegaard <dr@jones.dk> writes:
>
> > I have noticed several times package changes like the following (from
> > cairomm entering testing today):
> >
> > * debian/control:
> > - Drop build dependencies on doxygen and graphviz, since upstream
> > now ships the generated documentation
> >
> >
> > Feels wrong to me to redistribute when e.g. html files clearly are not
> > the preferred form of editing for upstream.
>
> To me, that doesn't sound all that troubling: we do use other generated
> files that upstream ships more often than not: configure, Makefile.ins -
> and so on. Though, those are rarely shipped in the binary package, but
> still: we do not build-depend on the tools that generate these.
>
> Technically, upstream could do anything in those files, write them by
> hand instead of generating from configure.ac, and include that in the
> distributed tarball, potentially under a non-free license.
>
> In any case: even if upstream shipts generated content, as long as the
> source is shipped aswell, all is fine and well, in my opinion. The
> _source_ needs to be in the preferred form of modification. If it
> contains generated files aswell, that doesn't matter all that much: the
> source is still there. You just don't have to use it, if the result
> would be the same anyway.

It's better to build the pre-generated files from source in case you
need to modify the source. It's easier to just modify for example
configure.ac instead of modifying it and figuring out how to rebuild the
pre-generated files, especially when you do security fixes or stable
release updates.

--
Benjamin Drung
Debian & Ubuntu Developer
 
Old 06-04-2011, 05:21 PM
"Bernhard R. Link"
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

* Benjamin Drung <bdrung@debian.org> [110604 14:22]:
> It's better to build the pre-generated files from source in case you
> need to modify the source. It's easier to just modify for example
> configure.ac instead of modifying it and figuring out how to rebuild the
> pre-generated files, especially when you do security fixes or stable
> release updates.

Changing configure.ac does not really sound like a very minimal
change to me.

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110604172134.GA31874@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110604172134.GA31874@pcpool00.mathematik.uni-freiburg.de
 
Old 06-04-2011, 06:29 PM
Russ Allbery
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

"Bernhard R. Link" <brlink@debian.org> writes:
> * Benjamin Drung <bdrung@debian.org> [110604 14:22]:

>> It's better to build the pre-generated files from source in case you
>> need to modify the source. It's easier to just modify for example
>> configure.ac instead of modifying it and figuring out how to rebuild
>> the pre-generated files, especially when you do security fixes or
>> stable release updates.

> Changing configure.ac does not really sound like a very minimal
> change to me.

It often is, though. For example, I've modified several configure.ac
files to just add a pattern for GNU Hurd to the pattern for Linux that
controls some behavior that also works on the Hurd. It's about a seven
character change.

I still use the upstream's generated files most of the time because it's
less complex. But I'm increasingly liking the idea of packaging an
upstream release tag from a Git repository instead, at which point it's
nice and clean to run the autotools during the build. The only thing that
I still don't like about that is that it means the Debian packaging is
based on a generated tarball that doesn't have any direct relationship
with the tarball that upstream distributes.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8739jp1mdi.fsf@windlord.stanford.edu">http://lists.debian.org/8739jp1mdi.fsf@windlord.stanford.edu
 
Old 06-04-2011, 06:58 PM
Gergely Nagy
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

Benjamin Drung <bdrung@debian.org> writes:

> Am Samstag, den 04.06.2011, 14:10 +0200 schrieb Gergely Nagy:
>> Jonas Smedegaard <dr@jones.dk> writes:
>>
>> > I have noticed several times package changes like the following (from
>> > cairomm entering testing today):
>> >
>> > * debian/control:
>> > - Drop build dependencies on doxygen and graphviz, since upstream
>> > now ships the generated documentation
>> >
>> >
>> > Feels wrong to me to redistribute when e.g. html files clearly are not
>> > the preferred form of editing for upstream.
>>
>> To me, that doesn't sound all that troubling: we do use other generated
>> files that upstream ships more often than not: configure, Makefile.ins -
>> and so on. Though, those are rarely shipped in the binary package, but
>> still: we do not build-depend on the tools that generate these.
>>
>> Technically, upstream could do anything in those files, write them by
>> hand instead of generating from configure.ac, and include that in the
>> distributed tarball, potentially under a non-free license.
>>
>> In any case: even if upstream shipts generated content, as long as the
>> source is shipped aswell, all is fine and well, in my opinion. The
>> _source_ needs to be in the preferred form of modification. If it
>> contains generated files aswell, that doesn't matter all that much: the
>> source is still there. You just don't have to use it, if the result
>> would be the same anyway.
>
> It's better to build the pre-generated files from source in case you
> need to modify the source. It's easier to just modify for example
> configure.ac instead of modifying it and figuring out how to rebuild the
> pre-generated files, especially when you do security fixes or stable
> release updates.

That, I agree with. However, if the upstream build system does not
rebuild what needs to be rebuilt when I modify the sources, I'd consider
that as a bug, and would make upstream fix it (or at least, try to make
him fix it).

As a maintainer, I kinda want to know the software's build system well
enough to be able to rebuild stuff if so need be, even if I did not do
that in the Debian package before.

As long as the sources are there, I have the ability to fix a bug
directly there. Having generated files there helps until I don't need to
regenerate them, thus, I don't see nothing wrong with using them.

Much like I don't see an issue with using the autotools generated stuff,
nor the graphics, that were exported from an xcf file, for example. I'm
not going to build-depend on gimp to be able rebuild graphics. The pngs
are fine with me. Corner case, yes, but the point remains.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aadxfmoc.fsf@luthien.mhp">http://lists.debian.org/87aadxfmoc.fsf@luthien.mhp
 
Old 06-04-2011, 07:54 PM
Jonas Smedegaard
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

On 11-06-04 at 11:29am, Russ Allbery wrote:
> "Bernhard R. Link" <brlink@debian.org> writes:
> > * Benjamin Drung <bdrung@debian.org> [110604 14:22]:
>
> >> It's better to build the pre-generated files from source in case
> >> you need to modify the source. It's easier to just modify for
> >> example configure.ac instead of modifying it and figuring out how
> >> to rebuild the pre-generated files, especially when you do security
> >> fixes or stable release updates.
>
> > Changing configure.ac does not really sound like a very minimal
> > change to me.
>
> It often is, though. For example, I've modified several configure.ac
> files to just add a pattern for GNU Hurd to the pattern for Linux that
> controls some behavior that also works on the Hurd. It's about a
> seven character change.
>
> I still use the upstream's generated files most of the time because
> it's less complex. But I'm increasingly liking the idea of packaging
> an upstream release tag from a Git repository instead, at which point
> it's nice and clean to run the autotools during the build. The only
> thing that I still don't like about that is that it means the Debian
> packaging is based on a generated tarball that doesn't have any direct
> relationship with the tarball that upstream distributes.

Interesting. I used to avoid that approach without reflecting much on
why - just doing because early on in my life of Debian Maintainer I was
taught "it is bad to override upstream-provided autotools". But you are
right - it makes good sense to do sometimes.

What I do is use upstream provided tarballs, then put aside
autotools-generated files, then autogenerate myself, and in the clean
rule put back the upstream-provided files (because I want not only
minimal required build routines idempotent but also building with
git-buildpackage).

Putting aside and restoring is doable in only a few careful lines in the
rules file.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
 
Old 06-04-2011, 09:54 PM
Tshepang Lekhonkhobe
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

On Sat, 2011-06-04 at 14:10 +0200, Gergely Nagy wrote:
> (Provided that said action does not cause unwanted side effects, like
> the documentation being out of date, because upstream forgot to
> regenerate them before distribution - but that falls under the "upstream
> to not be a moron" above

I see this was some sort of joke, but did you have to call a volunteer
that made a mistake a moron? Did you have to repeat that negative label
twice?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1307224444.12430.3.camel@debian">http://lists.debian.org/1307224444.12430.3.camel@debian
 
Old 06-04-2011, 11:16 PM
Steve Langasek
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

On Sat, Jun 04, 2011 at 11:54:00PM +0200, Tshepang Lekhonkhobe wrote:
> On Sat, 2011-06-04 at 14:10 +0200, Gergely Nagy wrote:
> > (Provided that said action does not cause unwanted side effects, like
> > the documentation being out of date, because upstream forgot to
> > regenerate them before distribution - but that falls under the "upstream
> > to not be a moron" above

> I see this was some sort of joke, but did you have to call a volunteer
> that made a mistake a moron? Did you have to repeat that negative label
> twice?

Do you have to make a fuss on a public mailing list every time you don't
like the tone someone uses? I find getting mired in meta discussions about
people's word choice much more damaging to the climate of our mailing lists
than the occasional rude remark.

</deliberate_irony>

And I don't think there was anything inappropriate about Gergely's message,
either. Referring to a *hypothetical* upstream as a moron is whimsical, not
offensive.

--
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
 
Old 06-05-2011, 12:28 AM
Tshepang Lekhonkhobe
 
Default Ok to use upstream doumentation as-is (i.e. not regenerate)?

On Sat, 2011-06-04 at 16:16 -0700, Steve Langasek wrote:
> On Sat, Jun 04, 2011 at 11:54:00PM +0200, Tshepang Lekhonkhobe wrote:
> > On Sat, 2011-06-04 at 14:10 +0200, Gergely Nagy wrote:
> > > (Provided that said action does not cause unwanted side effects, like
> > > the documentation being out of date, because upstream forgot to
> > > regenerate them before distribution - but that falls under the "upstream
> > > to not be a moron" above
>
> > I see this was some sort of joke, but did you have to call a volunteer
> > that made a mistake a moron? Did you have to repeat that negative label
> > twice?
>
> Do you have to make a fuss on a public mailing list every time you don't
> like the tone someone uses? I find getting mired in meta discussions about
> people's word choice much more damaging to the climate of our mailing lists
> than the occasional rude remark.
>
> </deliberate_irony>



> And I don't think there was anything inappropriate about Gergely's message,
> either. Referring to a *hypothetical* upstream as a moron is whimsical, not
> offensive.

Perhaps I was being too sensitive there. Sorry for soiling this thread.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1307233699.15003.13.camel@debian">http://lists.debian.org/1307233699.15003.13.camel@debian
 

Thread Tools




All times are GMT. The time now is 10:46 PM.

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