On Wed, 25 Apr 2001, Wichert Akkerman wrote:
> Previously Henrique M Holschuh wrote:
> > The package diverts the outdated files /usr/share/automake/config.
>
> I doubt that is a good idea, it would be much nicer to coordinate this
> with the libtool and automake package mainta
Hello fellow developers,
We've had a few problems with widespread deployment of outdated config.guess
and config.sub files, which result in some archs not being supported. So
far, the only solution available to this problem was to file a bug against
every package with outdated files everytime a up
On Wed, 04 Apr 2001, Julian Gilbey wrote:
> I would like to put this amendment into the next version of policy in
> the next few weeks. However, the scripts still do not appear to be in
> the sysvinit or file-rc packages; do you need help here? This can't
> go into policy until that's happened.
On Tue, 03 Apr 2001, Jean-Philippe Guérard wrote:
> ie you install a init script with update-rc.d, but you have no way
> of knowing which script is installed, and which runlevel it is
> installed for.
You have two classes of code that needs to interact with the initscripts:
those who should not ev
On Mon, 02 Apr 2001, Jean-Philippe Guérard wrote:
> The Debian policy specifies (10.3.1) that maintainer scripts should not
> assume whether or not a specific implementation of the handling of
> init scripts is used.
>
> It provides a tool, update-rc.d, that has to be used to install or
> remove a
Package: debian-policy
Version: 3.5.2.0
Severity: wishlist
It is about time we recognize the truth. We have been constantly called as
the most elitist of the GNU/Linux distribuitons, and this is true.
So, I propose we make clear that we are indeed '1337 and rename the
debian/rules file to debian/
I second this proposal, on the condition that patches are sent to the BTS
(or NMUs are made) so as to avoid the possibility of packages being left out
of woody due to the surge of RC bugs this proposal will generate.
--
"One disk to rule them all, One disk to find them. One disk to bring
them
On Sun, 25 Mar 2001, Anthony Towns wrote:
> --- policy.sgml.old Sun Mar 25 22:33:31 2001
> +++ policy.sgml Sun Mar 25 22:33:52 2001
> @@ -181,7 +181,7 @@
>
>
> These classifications are roughly equivalent to the bug
> - severities important (for must or
> +
On Thu, 15 Mar 2001, Henrique M Holschuh wrote:
> every machine that ever needs to build a certain package JUST because you
> dislike dpkg-statoverride usage in postinst? It looks like you're trying to
That was out of line, and I apologise. Please read "JUST because of a
dislike
On Thu, 15 Mar 2001, Anthony Towns wrote:
> On Thu, Mar 15, 2001 at 01:15:37PM +0100, Wichert Akkerman wrote:
> > Previously Anthony Towns wrote:
> > > What's special about dynamic u/gids? You just make sure the user/group
> > > exists in the preinst, then let dpkg unpack it to the correct id. No n
On Tue, 13 Mar 2001, Julian Gilbey wrote:
> On Tue, Mar 13, 2001 at 11:56:59AM -0300, Henrique M Holschuh wrote:
> > On Mon, 12 Mar 2001, Ben Gertzfield wrote:
> > > If I understand dpkg-statoverride correctly, mentioning that
> > > dpkg-statoverride is not to be call
On Mon, 12 Mar 2001, Ben Gertzfield wrote:
> If I understand dpkg-statoverride correctly, mentioning that
> dpkg-statoverride is not to be called from maintainer post/pre
> install scripts should also be added.
I oppose that. How am I supposed to have dynamically-created UIDs [that are
not created
On Fri, 02 Mar 2001, Richard Braakman wrote:
> On Fri, Mar 02, 2001 at 10:43:21AM -0300, Henrique M Holschuh wrote:
> > I have doubts we need to add such to policy... Maybe mentioning "make sure
> > you update the location of files in the documentation you are packaging&q
On Fri, 02 Mar 2001, Oliver Elphick wrote:
> Configuration file locations are oftenn changed for Debian. However the
> manual pages still refer to the upstream locations. This makes it very
> difficult to find out where to make changes, particularly for new users.
AFAIK what you describe is a bu
Package: debian-policy
Version: 3.5.2.0
Severity: wishlist
This proposal has ties to #76868 (invoke-rc.d), #60979 (what /etc/init.d/xxx
restart does?).
"Action" in the text below is the *first* parameter specified for an init
script (e.g.: in /etc/init.d/foo start, "start" is the action).
The na
On Sun, 25 Feb 2001, Julian Gilbey wrote:
> Policy should now require packages to specify build time dependencies
> (i.e., packages which require ... MUST specify...)
seconded.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In
On Fri, 23 Feb 2001, Sean 'Shaleh' Perry wrote:
> possibly hazardous/security threatening/will cause bugs later items. So, do I
> leave it and let people use overrides? Or do i remove them and hope the rest
> of debian does not miss an accidental permission setting from upstream?
Leave it in. Th
On Fri, 23 Feb 2001, Julian Gilbey wrote:
> This has now been seconded twice; it should have its status changed to
> "accepted" and I guess that the sysvinit and file-rc packages should
> have bugs against them to include the necessary scripts. Perhaps they
The file-rc scripts are not written yet
On Tue, 20 Feb 2001, Martin Michlmayr wrote:
> * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> [20010220 12:49]:
> > So, perhaps we should drop the bar a little. If your package is not
> > at least 3.x.x, it gets held.
>
> I second this.
So do I. 2.x doesn't get the GPL copyright, FHS or logrotate ri
On Fri, 09 Feb 2001, Wichert Akkerman wrote:
> I still completely fail to see why this is exactly needed. The only
> reason I can see is detecting bogus uploads where they change from
> Debian native (ie without .diff.gz) to non-native or the other way around.
>
> And guess what: katie already det
On Fri, 09 Feb 2001, Wichert Akkerman wrote:
> Forcing one to encode Debian-nativeness in the Package version is
> just trying to put too much data in the version imho.
Well, it's either that or change the build tools... either by adding a flag
to the control file, or by changing dpkg-buildpackage
On Fri, 09 Feb 2001, Brian May wrote:
> My only concern with the policy change, is what defines a "native
> package"?
Whatever defined it before. It is not in policy, AFAIK. Probably some doc or
even code in the dpkg package is the authoritative source for the
definition... Just like dpkg-source's
On Thu, 08 Feb 2001, Wichert Akkerman wrote:
> FWIW, if this change gets accepted all my currently Debian native package
> will suddenly no longer become Debian native and get an empty diff file.
Yes, that would be expected.
Personally, I'd rather see empty .diff.gz's than people giving up their
Package: debian-policy
Version: 3.5.0.0
Severity: wishlist
Currently it is impossible to verify when a source package is mistakenly
uploaded in debian-native source format (.tar.gz + .dsc) instead of
non-native source format (.orig.tar.gz + .diff.gz + .dsc).
Such broken uploads are reasonably com
On Sun, 04 Feb 2001, Manoj Srivastava wrote:
> >>"Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes:
> I don't see where the source or binary package enter the
> picture here. What am I missing?
Currently, policy says NOTHING about native packa
On Sun, 04 Feb 2001, Bas Zoetekouw wrote:
> > Well, I want us *all* to get bug reports. And when I get out the NM
> > queue, I'll want to get the bug reports for my packages. But right
> > now, a significant percentage of AbiWord bug reports are never seen by
> > the developers.
>
> Well, this
(all CC:s removed)
On Sun, 04 Feb 2001, Manoj Srivastava wrote:
> -> if yes, do as you wish. But be warned that I'll be proposing in policy
> Henrique>that *SOURCE* (not binary) native packages be forbidden
> Henrique>debian revision fields (there's a good reason for that,
> Henrique>
On Sun, 04 Feb 2001, Siggi Langauf wrote:
> So we can keep this bug closed and I can turn to the 0.3.7 and 0.4.0
> releases again?
IMHO for what it's worth, yes, this bug report should be closed.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the dark
On Sun, 04 Feb 2001, Siggi Langauf wrote:
> On Sun, 4 Feb 2001, Adrian Bunk wrote:
> > consider the situation when an older version of your package is in frozen
> > and you must fix a RC bug but the release manager won't allow you to
>
> In that case, I'd have to make a second branch, anyway.
> Th
On Sun, 04 Feb 2001, Nicolás Lichtmaier wrote:
> > Native is best choosen for packages which are not expected to be used
> > outside of Debian, btw. If I were xine's upstream, I'd package it as
> > non-native. The non-native format is more flexible.
>
> Packaging it native is a perfectly valid
On Sun, 04 Feb 2001, Siggi Langauf wrote:
> Currently, it's very unlikely that I release a debian-only update of
> xine. There's a new upstream version every two weeks (at maximum,
> averagely every week). Even if I would make a "debian only" change a few
> hours after a normal release, there are t
On Sun, 04 Feb 2001, Adrian Bunk wrote:
> I have with Siggi Langauf (the maintainer of xine) a discussion in bug
> #84754 whether xine is a Debian native package or not.
We've discussed something like this in -policy recently.
Basically, here's the guidelines you should follow to decide wether yo
On Sun, 04 Feb 2001, Brian May wrote:
> No! I mean for binary deb packages only, where a rebuild is required,
> eg. for a new version of the package.
Ok. So you propose we forbid debian revision numbers for SOURCE native
packages, but allow them for binary-only NMU's ?
Seems fine to me. That woul
On Sun, 04 Feb 2001, Brian May wrote:
> Although for native packages (which should not already have a Debian
> revision number), -# should probably be appended instead, so the
> version stays the same.
No. That is the same as adding a Debian revision (native packages are
forbidden to have '-' in t
On Sat, 03 Feb 2001, Brian May wrote:
> So obviously 1 is not relevant but 2 still is. eg. consider a package
> that was built against a buggy library, and the package has to be
> rebuilt in order to fix the problem. No source needs to change, so
> updating the version number is (IMHO) an overkill.
On Sat, 03 Feb 2001, Wichert Akkerman wrote:
> Previously Manoj Srivastava wrote:
> > I feel that native packages should not have a debian revision,
> > but not strongly enough or with reasons to be able to convincingly
> > argue that feeling be made mandatory in policy.
>
> The way I tend t
Apparently, many uploads of non-native packages without a diff and
.orig.tar.gz are happening (i.e: the packages are being wrongly built as
native debian packages). We need a machine-enforceable way to avoid this, as
talks with other developers implied those broken uploads are rather common.
One e
On Sat, 27 Jan 2001, Brian May wrote:
> >>>>> "Henrique" == Henrique M Holschuh <[EMAIL PROTECTED]> writes:
> Henrique> In other words, if this bug is deemed to be correct, we
> Henrique> will have to add hard-link support to dpkg and
>
On Fri, 26 Jan 2001, Ben Collins wrote:
> On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote:
> > foo-dev (2.1) /usr/include/foo.h
> > /usr/lib/libfoo.so (copy of actual library)
>
> Can we say archive, system, mirror and update bloat horror!? DO you
> reali
On Thu, 18 Jan 2001, Steve Greenland wrote:
> On 17-Jan-01, 23:28 (CST), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> > Does someone have an interest in pushing these proposals
> > through? What is needed is to have the skeleton code written by
> > Julian fleshed out, add support for fi
On Wed, 17 Jan 2001, Manoj Srivastava wrote:
> Does someone have an interest in pushing these proposals
> through? What is needed is to have the skeleton code written by
Please have a look at policy proposal #76868 (invoke-rc.d). It has strong
ties to both #60979 (restart, maybe-restart)
On Sat, 09 Dec 2000, Karl M. Hegbloom wrote:
> [ObCrossposts: We should decide what list to discuss this on.]
Please do so in debian-policy (reply-to: set). The BTS bug number for this
problem is 79210.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and
Package: packaging-manual
Version: 3.2.1.0
Severity: normal
The packaging manual states that foo-1.2.3.orig.tar.gz must unpack to
foo-1.2.3.orig.
However, not only this is not true (dpkg-source apparently deals well with
the tarball unpacking to just about anything, as long as it is
one-directory
On Thu, 23 Nov 2000, Matt Kraai wrote:
> On Thu, Nov 23, 2000 at 09:13:08AM -0200, Henrique M Holschuh wrote:
> > This is the final revision of the invoke-rc.d script and proposal, Posted as
> > a changelog to minimise bandwidth usage.
>
> I hope not, as there is a typo
This is the final revision of the invoke-rc.d script and proposal, Posted as
a changelog to minimise bandwidth usage.
Changelog:
(policy proposal)
* no changes since last changelog
(invoke-rc.d)
* less verbosity on common situations
- no error message on deny unless --disclose-deny
On Wed, 22 Nov 2000, Anthony Towns wrote:
> You could also reasonably map all the maintainer scripts invocations of
> invoke-rc.d to no-ops in order to just leave all services running during
> an upgrade (rather than possibly shutting them down for an extended period,
> say).
This is what I'd reco
On Fri, 17 Nov 2000, Anthony Towns wrote:
> On Thu, Nov 16, 2000 at 02:19:50PM -0200, Henrique M Holschuh wrote:
> Well, really they wouldn't even need to read the docs; it should be obvious
> from what gets displayed on screen as to what's happening. Either:
> Rest
On Thu, 16 Nov 2000, Anthony Towns wrote:
> Despite how it may appear, I'm not doing this merely to be obnoxious. :(
Ok, don't worry.
> On Wed, Nov 15, 2000 at 09:13:10AM -0200, Henrique M Holschuh wrote:
> > As I said, they're there to avoid confusing the user.
New revision of the policy proposal is attached.
Changelog:
(policy)
* Remove any mentions of 'restart-if-running'.
'restart-if-running' will be proposed separately.
(invoke-rc.d)
* Remove any mentions of 'restart-if-running' as well as any
related code.
* "restart" out-of-run
On Wed, 15 Nov 2000, Anthony Towns wrote:
> > I could leave the more verbosy stuff that fallbacks cause, but THAT would
> > give quite a lot of room to user confusion. When someone starts the holy
> > war against the amount of crap a upgrade sends to the screen, and AFTER the
> > TeX and emacsen-r
On Wed, 15 Nov 2000, Anthony Towns wrote:
> On Tue, Nov 14, 2000 at 12:06:36PM -0200, Henrique M Holschuh wrote:
> If you hide error messages, you'll make it harder for people to notice
> bugs in their init scripts when they upload a new package (let's see,
> yup, seems to wo
(sorry for the Delay, workload has skyrocked for a few days -HMH)
On Mon, 13 Nov 2000, Anthony Towns wrote:
> I still don't like restart-if-running though. I don't think "if"s should be
> in the arguments, and I'd be much more inclined towards something like:
>
> if [ `/etc/init.d/foo statu
On Sun, 12 Nov 2000, Chris Waters wrote:
> I have a question about this part. Are we planning to assume that all
> scripts in init.d support this argument? If so, we may be in trouble
No, supporting restart-if-running is optional. And, as it's defined in
policy as optional, if something will bre
Hmm... This cold must be getting to me worse than I thought.
I've retitled the bug. This message is being sent just so that people will
actually know what was submitted at a glance ;-)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind
Package: debian-policy
Version: 3.2.1.0
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This issue has been discussed in both debian-devel and debian-policy, and
all threads seem to have stalled. Therefore, I am submitting it to the BTS.
Should this proposal be accepted, manpage
On Mon, 06 Nov 2000, Manoj Srivastava wrote:
> How about this psuedo diff (I made the second paragraph a
> footnote, and hence informative rather than normative). When we have
> better compliance, we can switch to a should, and then a must,
> directive.
Ok.
I propose (informally) that w
On Mon, 06 Nov 2000, Paul Slootman wrote:
> Nowhere in policy do I see that it is forbidden to pass extra
> parameters. However, your invoke-rc.d does in fact explicitly
> forbid it (it prints an error and exits with 103).
You're right. I'll change the interface and implementation for invoke-rc.d.
On Sun, 05 Nov 2000, Manoj Srivastava wrote:
> packages buggy''. Indeeed, anything like this should probably be
> introduced as a recommendation; and non-compliance should be deemed a
I will change the proposal to recommend the use of invoke-rc.d, and add a
warning that 'in the future' usage of
Attached, you'll find the revised invoke-rc.d executable for sysvinit,
policy change proposal and interface specs for invoke-rc.d and policy-rc.d.
Changelog:
* `maybe-restart' renamed to `restart-if-running';
* Fallback action for `restart' attempted out-of-runlevel
is now `restart-if-runn
On Thu, 02 Nov 2000, Branden Robinson wrote:
> On Thu, Nov 02, 2000 at 10:43:34AM -0500, Mark Rahner wrote:
> > I'm just a lurker (at this point) and I'm not out to make work for anyone so
> > take my comments for what they're worth. In answer to your question, I'm a
> > big
> > fan of extreme cl
On Thu, 02 Nov 2000, T.Pospisek's MailLists wrote:
> I absolutely don't understand why you want to introduce a "maybe" restart
> instead of sanely defining the semantics of the "existing" restart and
> correctly implementing it.
Because redefining restart is not possible in practice. It is as simp
[-policy added to CC: list]
On Thu, 02 Nov 2000, Mark Rahner wrote:
> Henrique M Holschuh wrote:
> > maybe-restart means exectly that: restart only if currently running.
>
> I had been wondering about this. It's a shame this isn't called
> restart-if-running.
On Tue, 31 Oct 2000, Julian Gilbey wrote:
> On Tue, Aug 29, 2000 at 11:52:34PM -0500, Manoj Srivastava wrote:
> > #60979: What /etc/init.d/xxx restart does?
> > status: restart stops and starts the program, perhaps we need a
> > start-rc.d script We now are waiting for code.
> > Act
On Tue, 31 Oct 2000, Steve Greenland wrote:
> > + `update-rc.d' and the system administrator. Also, requests to restart
> > a
> > + service out of its intended runlevels are changed to a stop request.
>
> The last sentence causes a problem in the following (contrived?)
> scenario.
>
> 1.
This RFC addresses bugs #20373 and #60979, as well as a recent subthread in
debian-policy.
Hello Developers,
The main body of this message is only a "why the heck do we need this stuff"
clarification and overview of the issue and proposal itself... the real
goodies are in attachments.
Please r
On Tue, 17 Oct 2000, Roland Rosenfeld wrote:
> daemon is running yet, but we should introduce one and fixate this in
> the policy).
I'm on it. The code is ready and tested (for rc?.d, but I'll code the
file-rc version if the thing is accepted -- and it WAS designed to work with
whatever rc scheme
Package: debian-policy
Version: 3.2.1.0
I have coded a partial solution to this problem before I read this bug. it's
not as nice as a start-rc.d script, but it IS simpler (OTH, it requires more
code to be added in the postinst scripts, and it's a less generic solution).
I can, however, write a st
67 matches
Mail list logo
