Package: debian-policy
Version: 3.5.9.0
Severity: normal
In the footnote under "2.3.9.1. Prompting in maintainer scripts",
we read:
[1] 4% of Debian packages [see Debconf stats
(http://kitenet.net/programs/debconf/stats/)] currently use
`debconf'
The proper URL to use is http://auric.
u
would need to cite an actual problem which happens if someone uses
4.2CR2 rather than 4.2.
Otherwise, John, I think you're just obsessing that the numbers are
right, and we're all too busy to worry about such trivialities. The
functionality is the thing.
--
...Adam Di Carlo..<[EMAIL PROTECTED]>...http://www.onshored.com/>
that it will be useful to more people I'd call that a win.
> That is what I am proposing.
No, you're proposing making the debian-installer effort more
difficult, in the name of some kind of wierd abstract "elegance", the
only benefits of which are aesthetic. At least, that
ir own tree.
Requiring all these packages to be built at debian-installer build
time seems to add undue headache to the the debian-boot folks and
porters. I like that they are available separately in built form for
testing and use...
--
...Adam Di Carlo..<[EMAIL PROTECTED]>...http://www.onshored.com/>
Adrian Bunk <[EMAIL PROTECTED]> writes:
> Current policy says:
>
> <-- snip -->
>
> `standard'
> These packages provide a reasonably small but not too limited
> character-mode system. This is what will install by default if
> the user doesn't select anything
To: Anthony Towns
Cc: debian-policy@lists.debian.org
Subject: Re: Priorities
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL
Buddha Buck <[EMAIL PROTECTED]> writes:
> if the task-* packages are intended solely for the
> purview of tasksel, why put them in the main
> Packages.gz file? Why not distribute the dependency
> information as part of the tasksel package?
Because that's a huge pain in the butt, doesn't scale, a
Sorry, I'm not on debian-policy, but since I was one of the ones who
lobbied for task packages, just a few random thoughts.
Anthony Towns writes:
> I don't really understand task packages. I'd assume that they're there
> to make it easy for people to do some particular common tasks (setup a
> de
In message <[EMAIL PROTECTED]> you wrote:
>Previously David Huggins-Daines wrote:
>> For example, I did an install with tasksel. I selected the SGML
>> tasks. PSGML depends on:
>>
>> Depends: emacs19 | emacs20 | xemacs21, sgml-base, sgml-data
>
>Eww. Does this really imply that you can't install
>It's also current policy. I tacked it on only for reference. I'm not
>accepting amendments that change that paragrpah, because I am only changing
>a prt of policy to document existing practice, but you're quite welcome to
>make your own proposal.
I would, but I'm too busy saving the world.
>>| 2.3.6. The base system
>> --
>>| The base system is a minimum subset of the Debian GNU/Linux
>>| system that is installed before everything else on a new system.
>>| Thus, only very few packages are allowed to go into the base
>>| system to keep the required disk
> On Wed, Sep 08, 1999 at 04:07:42PM -0400, Alexander Pennace wrote:
> > since bo, point releases have been identified like 1.3r2.
Joseph Carter <[EMAIL PROTECTED]> writes:
> I'd rather fix the 1.3r2 problem and go back to 1.3.2, it's less confusing
> and only the greenest of users couldn't figur
Raul, bug# 22308 has been fixed. If you agree, could you please
close the bug? Since I'm not the submitter and it's a policy bug,
I'm not comfortable closing it myself (feeling wimpy today).
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>
Santiago Vila <[EMAIL PROTECTED]> writes:
> On Tue, 1 Jun 1999, Joey Hess wrote:
> > A reccommendation would be fine. Perhaps it'd be more suited to go in the
> > developers reference than in policy?
> Yes.
>
> It is not needed that whatever we write about this is "normative", I just
> would li
Jason, I hadn't read back on all this discussion. I caught up a bit
more. Sorry to have you hash this out again.
I think your definitions and goals are good and useful.
However, I personally would weigh in, in the case of an upstream
.tar.gz file which dpkg-source can handle and doesn't have o
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> I like to consider the source code (.c files, etc) and it's transfer
> encoding (.tar.gz) to be seperate. if you repack it, or recompress it, all
> you are doing is changing the way it is delivered not what is being
> delivered which is really what we
Chris Waters <[EMAIL PROTECTED]> writes:
> I also disagree strongly with the reasons behind the proposal. If we
> need another CD, we should use another CD. Trying to fidget things to
> fit is a pointless exercise, certainly, in the long run, and probably
> in the short run as well. If we need
I think there are bugs in the packaging manual regarding pristine
source:
3.3. Source packages as archives
[...]
Original source archive - `_.orig.tar.gz'
This is a compressed (with `gzip -9') `tar' file containing the
source code from the upstream authors of the program.
Julian Gilbey <[EMAIL PROTECTED]> writes:
> By the way, is the Debian Constitution itself packaged?
Yes, in the developer's reference.
--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I have come to realize that there may be a better method of tracking
> the progress of proposals in the BTS.
> a) Pre discussion period, an idea is
> floated, and kicked around and wishlist bug, titled [PROPOSAL]
> polished for a bit
>
reassign 27906 developers-reference
thanks
This bug was filed against debian-policy but it was a bug in
developers-reference. This has been fixed in the new
developers-reference, which I am preparing to release; so of course
I'll close it when that's installed.
If there are unsolved Policy issu
reassign 30897 debiandoc-sgml
thanks
> Why has this bug been reassigned? When I got this bug report, I
> filed a separate bug report (#31033) to handle version.ent part.
> I very much would like to keep #30897 assigned to debiandoc-sgml,
> since the first part of this latter bug report is aimed
reassign 30897 debian-policy
thanks
This bug is a technical bug with the way that SGML source is shipping
in the debian-policy package (it doesn't need to go through the
proposal process, IMHO). The 'version.ent' file, which is
automatically generated from the changelog and holds version
informa
"Bob" == Bob Hilliard <[EMAIL PROTECTED]> writes:
> The following typo has been noted in policy.text.gz:
> Section 2.1.1., first line: The Debian Free Software Guidelines
> (DFSG) as is our definition of s/as is/is/ ^^ ^^
Note: since this is a simple typo and not a change to policy, it does
not
As some who has complained about overproceduralizing before, I'm a
little shocked by what seems to be ad hominom attacks and a lack of
understanding about the way we do things.
Let me start by saying that since the Ian Murdock days (or later), it
has been Debian Policy which has made us more than
In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> writes:
> It is not the job of policy maintainers to take a bug to the
> final acceptance. It is the responsibility of this mailing list, and
> quite frankly, most people on this mailing list have been doing
> little but tal
severity fixed 22308
thanks
The list, , is now listed as the
maintainer for the pacakge; therefore, all bug reports and followups
go to this list and this bug may be closed.
--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>
Package: debian-policy
Version: 2.5.0.0
Severity: normal
The list of current policy editors should be part of the documentation
shipped with the 'debian-policy' package, perhaps in
/usr/doc/debian-policy/README. Otherwise the information is hidden
and undisclosed, which seems like a cabal to me.
In article <[EMAIL PROTECTED]>, James LewisMoss <[EMAIL PROTECTED]> writes:
> Everyone changes policy based on discussion here.
Um, kinda. You have to go though a whole *process*.
Is Manoj proposing that this process be applied to these sub-policies.
No clear answer yet...
Adam> Are you really
I still don't really understand what is intended by moving
sub-policies into the policy manual. Is it intended that the Debian
Policy group take editorial control over the documents? Does the
package maintainer lose the ability to change the document, unless
they are also a policy editor?
More
In article <[EMAIL PROTECTED]>, Richard Braakman <[EMAIL PROTECTED]> writes:
> Manoj Srivastava wrote:
>> Since /etc/aliases is not a conf file belonging to any package
>> whatsoever, sectiosn 4.7 and 5.5 are not in conflict. I am closing
>> this report.
> This is not true. Both smail and sendmai
In article <[EMAIL PROTECTED]>, Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Mon, Nov 23, 1998 at 03:00:20AM -0500, Adam Di Carlo wrote:
>> Please see the the CVS live Debian Doc Project version, a
>> pre-release, now at 2.5.0.2, of the developer's refere
In article <[EMAIL PROTECTED]>, Santiago Vila <[EMAIL PROTECTED]> writes:
> I have discovered a little inconsistency in the policy.
> Section 5.5, "Mail transport agents" says:
>"/etc/aliases is the source file for the system mail aliases
> (e.g., postmaster, usenet, etc.)--it is the one whic
[Manoj, why do you never CC the bug report? Annoying.]
In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hi
>>> "Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> Would there be any objection to including the content of
Santiago> debian-emacs-policy.gz
In article <[EMAIL PROTECTED]>, Wichert Akkerman <[EMAIL PROTECTED]> writes:
> [1 ] (major crosspost)
> Previously Julian Gilbey wrote:
>> See my other mail to this list -- this is what release quite
>> happily does, and its man page doesn't say anything about it being
>> evil. Where would I (as a
In article <[EMAIL PROTECTED]>, Bob Hilliard <[EMAIL PROTECTED]> writes:
> The most recent version of packaging-manual is 2.4.1.2, while
> the most recent version of debian-policy is 2.5.0.0. I believe
> there has been agreement on the policy list that these documents
> would maintain paralle
In article <[EMAIL PROTECTED]>, Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> I won't learn debiandoc-sgml. It's application is so ridiculously
> limited, I wouldn't ever be able to justify the outlay in time. My
> entire reaction when Ian first introduced it was to smack my head
> and say, "
I have documented what I feel is the best practices for doing NMUs and
ports. This includes who can do an NMU/port, how long should wait for
a bug to be resolved by the maintainer, etc, etc.
I've tried to take a "middle ground" stance, which will keep the more
militant on this list satisfied, w
"Michael" == Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> As to putting something in policy, I'm sceptical---what real effect
> will it have? The people need to be told are least likely to pay
> attention to it.
I agree. W.R.T. debiandoc-sgml, is there any evidence anywhere that
Ardo has do
In article <[EMAIL PROTECTED]>, Zed Pobre <[EMAIL PROTECTED]> writes:
> [1 ] On Thu, Nov 12, 1998
> at 08:28:10PM -0800, Guy Maor wrote:
>> Either is fine as far as the archive scripts are concerned.
> Hm. Should I file a bug against dpkg, then, for not dealing
> with "contrib/net" properly
In article <[EMAIL PROTECTED]>, Ben Gertzfield <[EMAIL PROTECTED]> writes:
> Unfortunately, the Packaging Manual states the opposite of this:
> (chapter 12)
>Firstly, your package should install the shared libraries under
> their normal names. For example, the libgdbm1 package should install
In article <[EMAIL PROTECTED]>, Raul Miller <[EMAIL PROTECTED]> writes:
> Adam Di Carlo <[EMAIL PROTECTED]> wrote:
>> Raul, I really think the proof is in the pudding. If you can help
>> shape a working, easy enough to manage test suite, and start
>> fill
In article <[EMAIL PROTECTED]>, Ben Gertzfield <[EMAIL PROTECTED]> writes:
James> BTW: this isn't quite right; the source version doesn't
James> necessarily match the version number of the binary packages
James> (e.g. bash && libreadline). Some allowance must be made for
James> this.
> Ahh, so ho
In article <[EMAIL PROTECTED]>, Raul Miller <[EMAIL PROTECTED]> writes:
> Adam Di Carlo <[EMAIL PROTECTED]> wrote:
>> Raul has suggested to add test cases to debian/rules to certify
>> that a bug is gone. As much as I think our documentation should
>> encou
Raul has suggested to add test cases to debian/rules to certify that a
bug is gone. As much as I think our documentation should encourage
maintainers to write test cases, I believe this puts undue stress on
package maintainers. Moreover, if we do not have the cooperation of
the upstream maintain
In article <[EMAIL PROTECTED]>, Ben Gertzfield <[EMAIL PROTECTED]> writes:
> I've noticed that it's not policy for shared libraries' libblah-dev
> and libblah-dbg packages to depend on libblah1 (=${Source-Version})
> of the main library.
[...]
> Since the ${Source-Version} variable is not terribl
46 matches
Mail list logo
