On 12/1/17 11:19, Ian Jackson wrote:
> Is there some reason why exacdt standardisation of the filenames is
> necessary here ? For most of the uses I can think of, it is OK to
> look in a handful of files to see which one might answer the question.
I wrote the bug originally.
My goal was simply t
So since no one had anything to add, here is a concrete proposal. All
of this reflects current practice, I believe. Since the addition of
status_of_proc to /lib/lsb/init-functions, this has been quite
standardized in practice, and as I wrote earlier, more than half of the
affected packages are al
I would like to see whether we can create some progress around this bug.
Over the past few years I've been bugging packages to add the "status"
action to their init scripts. We currently have about 55% of packages
supporting this, including most of the most popular packages. We also
have a linti
On Monday 11 May 2009 09:49:31 Raphael Hertzog wrote:
> On Mon, 11 May 2009, Peter Eisentraut wrote:
> > Well, debuild calls dpkg-buildpackage most of the time, unless you give a
> > specific target (which would again possibly be of interest to those who
> > are interested in
On Monday 11 May 2009 00:06:09 Steve Langasek wrote:
> Or maybe I've misunderstood, and there are
> Debian developers who are building official packages for *upload* by
> calling debian/rules by hand, and that's what people are concerned about
> preserving while still getting the benefits of these
On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
> I thought it was generally recognized that it's a Bad Idea to implement
> config files using your interpreter's 'include' functionality, but that's
> basically what we have here.
Guillem pointed out one problem: Either you do it via a make inc
On Monday 04 May 2009 08:35:18 Guillem Jover wrote:
I like this proposal. A small nit:
> ,-- /usr/share/dpkg/build-options.mk
> # distro defaults
> FOO := distro
Please be sure to use
FOO = bar
instead of ":=", unless you have determined that you really wanted ":=". In
most cases it won't m
You might as well kill the entire priority business from packages altogether
and rely entirely on the overrides. The priority is, after all, not really a
property of a package but a property of the distribution.
As long as there is no practical way for a package maintainer to verify the
correc
Package: debian-policy
Version: 3.7.3.0
Severity: normal
There is some lack of clarity in the policy or perhaps some confusion among
packagers and thence inconsistencies among packages regarding the handling of
upstream changelog files. Policy says that upstream changelogs should be
installed as
Adding the version numbers to the enumerated licenses would be backwards
incompatible. Under the current policy, a package using the GPL 3 would be
required to link to the common licenses, but under this proposed change the
link would have to be removed again. Since the GPL 3 is here, you migh
As ntp comaintainer, I have so far resisted adding the time-daemon provides
because I find that the interface and the purpose is underspecified.
For example, nothing specifies whether a "time-daemon" should set the true
time, or a synchronized time, or just a reasonable time. There is nothing
The underlying question here was really, "Should PDF documentation be
installed compressed?" (Or PostScript or OpenOffice etc. in place of
PDF.) The policy is not worded precisely enough on that subject.
Obviously, you don't want to install HTML compressed. So I take it
that "text documenta
Package: debian-policy
Version: 3.7.2.1
Severity: normal
Section 9.3.3.2 "Running initscripts" reads:
The program invoke-rc.d is provided to make it easier for package
maintainers to properly invoke an initscript, obeying runlevel and
other locally-defined constraints that might limit
Goswin von Brederlow wrote:
> On the other hand the savings can be huge. Think about how many
> packages install latex and fonts and generate the documentation
> needlessly during build. Installing and purging latex as well as all
> the initex runs and font generation takes up a awfull lot of time
One question to ask is perhaps whether splitting the build dependencies
into several sets is useful at all, considering that the current state
of having effectively only one useful set has persistent for such a
long time.
Not a lot of people really understand the current definition, and this
p
Package: debian-policy
Version: 3.7.2.0
Severity: wishlist
I would like to see some clarifications for section 12.3 "Additional
documentation", in particular this:
Any additional documentation that comes with the package may be installed
at the discretion of the package maintainer. Text docum
16 matches
Mail list logo
