> [EMAIL PROTECTED] (Brian Mays) writes:
>
> > I've learned that too. They also don't read the documentation in
> > /usr/share/doc/.
"Thomas Bushnell, BSG" <[EMAIL PROTECTED]> added:
> And really, how could they? My *laptop* has 884 pa
Branden Robinson <[EMAIL PROTECTED]> wrote:
> Of course you realize that users do not, in general, read the extended
> descriptions of packages.
>
> This isn't your fault, just a bitter lesson I've learned over the past
> few years.
I've learned that too. They also don't read the documentation i
Sam Hartman <[EMAIL PROTECTED]> wrote:
> I'd be perfectly happy with a package that wanted some shared library
> only recommending or suggesting that shared library, provided that a
> wrapper script was included for the programs that did not function
> without the shared library to provide a usefu
ied. I
don't think that there is any one technically correct answer to this
question. Some resolutions are more consistent than others, however.
In the end, the answer depends on our philosophy of what constitutes a
package and what constitutes a dependency. I feel that my definitions
are closer to the original meanings of these two terms in the early
days of the Debian project, as reflected by the current wording of
the "Debian Policy Manual". My only hope is that, in the end, we are
consistent in the way in which we treat this problem.
Sincerely,
- Brian
--
Brian Mays
Debian Pcmcia-cs Package Maintainer
Nicol?s Lichtmaier <[EMAIL PROTECTED]> wrote:
> The idea of "if it's a bug in the software -> upstream, if it's Debian
> packaging -> Debian BTS" it's wrong and users shouldn't be told that.
Agreed. I don't advocate this.
Do we really need a change of policy for this? And how do we handle
case
[EMAIL PROTECTED] (Nicolas Lichtmaier) wrote:
> No, all bugs should be reported to Debian ...
I don't think that we should be in the business of telling anyone where
they should submit their bug reports. If the user wishes to deal with
the upstream developers directly, that is his or her preroga
> > Jon Eisenstein <[EMAIL PROTECTED]> writes:
> > > I recently filed a bug report (80092) against the nmh package
> > > regarding the location of its program files. It installs files
> > > into /usr/bin/mh, which isn't in the path, making running the
> > > program difficult until the reason is fo
[EMAIL PROTECTED] (Chris Waters) wrote:
> If the .deb needs to have one, why doesn't the .diff.gz, which is
> surely also GPL'd?
By the reasoning proposed by some on this list, it should.
> And what exactly *is* the license of a .dsc file? Is it legal for
> someone to distribute a .dsc by itsel
> On 1 Dec 2000, Manoj Srivastava wrote:
> > So tell us something we do not already know. Can we not refuse
> > to accept the validity of that argument?
[EMAIL PROTECTED] (Rando Christensen) wrote:
> Sure we can. I say, if RMS wants to banter and bicker and bitch
> and moan about it, instea
> The problem with that is, an aliened .deb has been received from
> us, thus counting as us distributing it. And the aliened .deb (and
> the resulting .rpm/slack .tgz) would not contain the gpl in this
> circumstance, which makes us be violating the gpl. apparently. =P
We are distributing aliened
> Brian Mays <[EMAIL PROTECTED]> writes:
> ... we should be including the GPLed sources in our packages.
[EMAIL PROTECTED] (Thomas Bushnell, BSG) replied:
> Except that the GPL section 3 explicitly says that providing a copy of
> the source on the same download site count
Brian Mays <[EMAIL PROTECTED]> writes:
> > By this definition, the "ls" binary itself is a complete work,
> > and should have an entire copy of the GPL built into it (readable
> > perhaps by typing "ls --GPL"). Certainly this is not the intent.
[E
Rando Christensen <[EMAIL PROTECTED]> writes:
> > Okay, so what's the problem with all gpl'd packages Depending on a
> > package called 'license-gpl' ?
[EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote:
> I suggested that, and it might be sufficient, but only if the tools
> like alien actually do e
> Programs on ftp sites are distributed over the net, they are not
> distributed over (on) ftp sites. IMHO the question is what medium
> is the work transported over/through during the copying from one
> person/computer to another, not what media the work is stored on
> before the copying.
Answer
Brian Frederick Kimball <[EMAIL PROTECTED]> wrote:
> Think of it this way: each "downloadable entity" that meets the above
> definition of "Program" needs to have the GPL inside it
Define "downloadable entity". This is the problem. Certainly a binary
executable or an individual file are both do
"Gustavo Noronha Silva (KoV)" <[EMAIL PROTECTED]> wrote:
> I think that "complete work" stands for every work that can be used
> in any installed system without missing parts... just like fileutils
> and debhelper. Debian distribution is for me an selection of complete
> works that are all package
put together by Ian Murdock <[EMAIL PROTECTED]>,
: from sources obtained from:
: prep.ai.mit.edu:/pub/gnu
I'd say that the user should look here for a copy of the upstream
source. It certainly will have a copy of the license. Of course, the
user can always get a copy of the source from us
Brian Mays wrote:
> > If here "you" refers to Debian, then we are not violating the GPL.
> > We distribute all of the packages, including "base", which contains
> > the a copy of the GPL. We distribute the program AND we give our
> > recipients a copy
Brian Frederick Kimball <[EMAIL PROTECTED]> wrote:
> Making the GPL available in a separate file that may or may not be
> received by the recipient of the GPLed Program does not constitute
> "giving" the GPL to the recipients of such a program "along with the
> Program". Is Debian giving the Lice
[EMAIL PROTECTED] (Anand Kumria) wrote:
> 3. [ distribution obligations for binaries ]
>
> a. [ accompany with source ]
>
> b. [ written offer of source ]
>
> c. [ provide corresponding info. received from your supplier ]
Actually, as Wichert mentioned, part 3 explicitly says
Previously Sean 'Shaleh' Perry wrote:
> > we do not remove the copyright. it is still in the source. I fail
> > to see why having 300 copies of the same file is needed.
[EMAIL PROTECTED] (Wichert Akkerman) writes:
> Reread my mail. Then realize that the GPL explicitly demands it.
The GPL says
> Do you think that "All the packages in the other sections" should be
> also modified to "All the packages in non-free or contrib sections" ?
No. Not really.
> What I wish to see is more explanation for users. Many ordinary users
> are not specialists in license. In many cases, they may not und
Josip Rodin <[EMAIL PROTECTED]> wrote:
> While I agree with you that this is a good idea, it is not current
> practice (at least I haven't seen any summaries in any newer packages,
> just the old ones). Policy says that the copyright file _must_ contain
> that summary, meaning that a considerable
Steve Greenland <[EMAIL PROTECTED]> wrote:
> It may be that we agree about the content of the README.Debian file: I
> think that what you're calling "a detailed list of changes to the
> upstream source" I would call "package.diff.gz" :-).
See the copyright file in my cpio package for an example o
Brian Mays wrote:
> > As was mentioned earlier in this thread, the README.Debian file is
> > best reserved for changes in the *behavior* of the package, not in
> > the changes to the source tree.
Steve Greenland <[EMAIL PROTECTED]> added:
> Assuming you're refer
Steve Greenland <[EMAIL PROTECTED]> wrote
> I agree that the summary should not be part of the changelog, but it
> never made sense to me that it was in the copyright file, either. The
> obvious place to me would be README.Debian.
As was mentioned earlier in this thread, the README.Debian file is
Anthony Towns wrote:
> Ditto; leaving it in copyright also makes it easy to remember to change
> it if the license becomes more free in the future: you're just editing the
> one file.
Actually, I had never thought of it that way, but it is true. I have had
a package go from non-free to free, a
Josip Rodin <[EMAIL PROTECTED]> wrote:
> But forcing the maintainer to make a nice little summary and update it
> every time s/he makes a change in the upstream sources is not really
> what most of us want, or what most of our users need ;o) I'm known for
> making pedantic changes in stuff I packa
Josip Rodin <[EMAIL PROTECTED]> wrote:
> I don't think the copyright file should explain the modifications made
> in the Debian package compared to the upstream one. The purpose of
> the changelog.Debian(.gz) file is to describe such changes (and any
> others), so this is a needless duplication of
"C. Cooke" <[EMAIL PROTECTED]> wrote:
> So. What about, instead of using something in the README.Debian,
> create a standard README.non-free, and include it in non-free
> packages. This makes more sense, and can include a standard "why
> non-free is generally bad" plus specific reasons.
I don't w
> Thanks to your consideration on this proposal, and sorry to be late in
> answering.
[ ... ]
> Well, what I wish to target with this proposal, is "let our users know
> more about the packages which they use".
[ ... ]
Thank you for your explanation. I have a better understanding now of
[EMAIL PROTECTED] (Taketoshi Sano) writes:
> With this consideration, I propose the modification of our policy below.
[ ... ]
> 2. The Debian Archive
> -
[ ... ]
> In order to avoid to be misconstrued, All the packages
> in the other sections than _main_ s
I (Brian Mays) wrote:
> > While I agree that it is probably a good idea for large packages, with
> > many binaries, to provide such a man page (in section 7, of course), it
> > makes no sense for packages in general. Personally, I think that such
> > policy would be a
> Policy says that any binary must come with a manpage. I would like to
> have the same for packages.
For every package? You must be kidding!!
> I just looked for a parser generator that outputs C++ code and found
> pccts. After installation I tried "man pccts", but that failed.
> /usr/doc/pcct
> "Stephane" == Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
Stephane> The current Policy manual says almost nothing about the
Stephane> README.Debian file. I suggest to add a section 6.8 (in
Stephane> the "Documentation" chapter) or something like that:
Stephane> 6.8 READM
Upon further reflection and experimentation, I have decided to end
this discussion by implementing rxvt's alternative method through
/usr/X11R6/bin. The problem that I discussed in my previous post can
be avoided by an aptly timed removal of the X11R6 alternative.
Brian
--
To UNSUBSCRIBE, email
Christian Schwarz <[EMAIL PROTECTED]> wrote:
> FSSTND 1.2 _and_ FHS 2.0 reads in section 4.1 /usr/X11R6 : X Window
> System, Version 11 Release 6:
> ``/usr/bin/X11 -> /usr/X11R6/bin
> /usr/lib/X11 -> /usr/X11R6/lib/X11
> /usr/include/X11 -> /usr/X11R6/include/X11
> In general, software
[EMAIL PROTECTED] (Herbert Xu) writes:
> In article <[EMAIL PROTECTED]> you wrote:
> > I think it should be permissible for scripts to use
> > /usr/bin/X11/, as that should be updated correctly.
> I think only the user should use /usr/bin/X11. When the transition
> comes, we'll need to uplo
Where should the links in /etc/alternatives point for X applications?
Should they point to /usr/bin/X11/app-name or /usr/X11R6/bin/app-name?
I can find nothing in Debian's policy manual that addresses this issue,
and there currently are at least two open bug reports (20407 and 20409)
on this.
It i
39 matches
Mail list logo
