loper community via the
debian-policy mailing list. Have you done this? If not, the work is not
"done".
But I would invite you to engage in this process and help to improve Policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
l not be fixed in stretch)
>
> (And the consequential lintian change.)
>
> I am not yet supplying patches for dpkg-source and for policy, because
> I think deprecating this feature will involve some discussion.
Seconded (the sentiment, and specifically the requested policy
ointer to
/usr/share/common-licenses. If people feel that it's insufficiently obvious
that this is the correct usage of the field, by all means, let's document
that better; but let's not make a backwards-incompatible change to the
syntax that doesn't benefit users of the file
vendor series files. It's not how any
downstream is actually managing their delta from Debian.
> We are actively working on the relevant processes and tools right now.
> Let's see what things look like once we reach the end of that work
> before escalating this bug anywhere.
--
St
our patches downstream
in Ubuntu only, and handle new Debian package versions via a manual merge.
There is no need for a third workflow to accommodate improperly-upstreamed
patches and breaking the behavior of dpkg-source.
--
Steve Langasek Give me a lever long enough and a Free O
nother arch.
I don't see a reason to use the field definition to try to guard against
that. Policy also doesn't prohibit you declaring Architecture: amd64 for
packages that you have failed to port to other architectures. This is
correctly enforced as distro policy, not as debian/control sy
f this requirement:
Ubuntu as a derivative was not consulted before ubuntu.series was inflicted
on us, but other derivatives who like this feature must be consulted before
upstream will un-break it for Ubuntu.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Dev
ir associated .service; there is no need for a
> sysvinit script in these cases, but Policy requires it.)
In my mind, the intent of the current policy language is to require an init
script matching any .service units, not for .socket or .timer units.
Perhaps the text should be refined to be sy
#x27;s postinst to exit 0 if:
- it ships a service,
- it is a new install or an upgrade on a system where the service was
previously started successfully, and
- the service fails to start in the postinst.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian
On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote:
> * Steve Langasek [230212 00:03]:
> > FWIW I think that it's the wrong thing to do if the "circumstances" include
> > reverse-dependencies on the package which expect to interact with the
> > se
ill also be applicable to systemd and should be moved up a section. I'm
not familiar enough with the mechanics of systemd to say whether this is the
case; eyeballs/wording tweaks welcome.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
> On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote:
> > Also, it's possible that some of the bits I've marked as upstart-specific
> > will also be applicable to systemd and should be moved u
On Wed, Jan 12, 2011 at 07:38:05PM +0100, Kurt Roeckx wrote:
> On Wed, Jan 12, 2011 at 12:50:21AM -0600, Steve Langasek wrote:
> > On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
> > > What should packages do that want to have their script run
> > >
That wiki document was not part of the DEP process.
--
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com
vironment, and require sanitized environments with no $CFLAGS set for
standard package builds?
(Anyway, isn't setting $CFLAGS in the environment exactly what
dpkg-buildpackage + dpkg-buildflags *does*?)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Dev
(bug
#577040), which I have asked Joey to sit on until policy is finalized and
various other key packages have implemented the necessary support (namely,
sysvinit and lsb-base).
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to s
the end of b-d installation the full build-dep
relationship is satisfied because a different package was pulled in (or
previously installed) that satisfies one of the other alternatives, the
build dependencies of the package as a whole are considered satisfied.
This was touched on briefly in <2011
On Sat, Feb 26, 2011 at 10:25:48PM +, Roger Leigh wrote:
> On Sat, Feb 26, 2011 at 10:39:51AM -0800, Steve Langasek wrote:
> > On Wed, Feb 23, 2011 at 05:52:27PM +0100, Cyril Brulebois wrote:
> > > Tiny question: you say it eases backports. But then backports get
> &g
o get anyone to care enough to implement it.
(Maybe this could make a reasonable GSoC project?)
--
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
. If the goal is to make sure installing a package in main
doesn't automatically pull in a package from non-free, then the main
alternative must be listed first.
Maybe "must be satisfied by default with only packages in main" expresses
this?
Or maybe this is splitting hairs and I s
On Fri, Mar 04, 2011 at 12:57:53PM -0500, Marvin Renich wrote:
> * Steve Langasek [110304 11:36]:
> > Although I agree with you that this parenthetical has been mistaken for
> > normative language and it should be clarified with regards to intent, the
> > clarification you
nk I was running Debian for about 5 years before I ever knew about this
file.
--
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 Developerhttp://www.de
DD short[1]. Seconds? Objections?
> Clarifications?
> A refreshed patch is attached for reference.
I am uncomfortable with the idea of Policy endorsing the use of
Turing-complete languages for configuration files. I think software should
use proper configuration libraries instead of this
Package: lintian
Version: 2.4.3
Severity: normal
It's been brought to my attention that lintian outputs a
'script-calls-init-script-directly' warning for scripts in /etc/ that
call scripts in /etc/init.d/:
W: samba: script-calls-init-script-directly ./etc/network/if-up.d/samba:30
As discussed
ly do this
checking when sourced. I think on some level the idea offends me, the same
way having C libraries call setuid() or exit() offends me. :) Also, this
check is only needed for those packages that *ship* an upstart job, and
surely those packages know who they are and can handle the conver
e for implementation and the interface packages should use to query these
paths.
Cc:ing the respective maintainer mailing lists for sign-off.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the
eal with any unexpected fallout.
Thoughts?
Thanks,
--
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 Developerhttp://www.debian.or
e to nudge this bug
along its way? :) Note that the dpkg implementation of what's described
here is imminent, so it would be good to have confirmation that it's ok on
the policy side for us to use this.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free
There are only three packages affected (libhwloc, liblouis,
liblouisxml) affected by the library path change; all of these should be
switched over to the final path before wheezy releases, so eglibc doesn't
have to carry transitional support for /usr/lib/i486-linux-gnu for more than
one rel
A discussion on debian-release partly satisfies the need for 1) and
addresses 2) not at all.
--
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
On Tue, Mar 29, 2011 at 05:21:59PM -0500, Jonathan Nieder wrote:
> Steve Langasek wrote:
> > http://wiki.debian.org/Multiarch/Bootstrapping
> > The current ld.so doesn't yet know about the final path (on i386), so
> > libraries can't switch to using it or
right now, or should we defer
amending policy until the prelim implementation is farther along in
unstable?
--
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
92> and
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482884>.
Yep. Thanks for reminding me of bug #482884, I'd completely forgotten that
this report was open!
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
only remaining rdeps of libmotif4
> > that I can see anywhere in Debian are the other members of the openmotif
> > source package.
> Yeah, this whole section looks completely obsolete. I think we should
> just remove it entirely. Objections or seconds?
Seconded.
--
Steve Langa
for ld.so. It has nothing
to do with include paths (or -dev packages in general) and should not be
abused like this.
--
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
an interface to declare additional -I arguments. So I'm not
convinced putting this in policy adds much value.
Cheers,
--
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
-time error that requires the user to
upgrade to the current gcc on i386 to fix.
--
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
uld need a new config
file (debian/users?), but I'm not sure it could be done with a very
debhelper-like syntax.
--
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
e file and remove it on purge.
So I don't think anything is actually missing in Policy?
(If one wishes to argue that /etc/sasldb2 is not a configuration file, then
it's also a policy violation for it to be under /etc.)
--
Steve Langasek Give me a lever long enough and a
On Sat, Apr 30, 2011 at 12:02:46PM +0200, Holger Levsen wrote:
> On Samstag, 30. April 2011, Steve Langasek wrote:
> > 10.7.3: If the existence of a [configuration] file is required for the
> > package to be sensibly configured it is the responsibility of the package
> >
On Sat, Apr 30, 2011 at 03:49:26PM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > (If one wishes to argue that /etc/sasldb2 is not a configuration file,
> > then it's also a policy violation for it to be under /etc.)
> It's basically similar to /etc/shad
I do object to telling maintainers they must not delete system users,
without also giving guidance on how and when to lock the accounts.
Sorry, no time at the moment to propose verbiage to reconcile this with your
concerns.
--
Steve Langasek Give me a lever long enough and a
an at least try to keep it from
rendering itself irrelevant.
Thanks,
--
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 Developerhttp://www.deb
proach, because it will
> both provide backwards compatibility with all older source packages, and
> use the rules if present in new ones.
The patch is outstanding; the make maintainer is TTBOMK currently
unavailable for Debian work. If there's a consensus on
debian-policy/devel/ctte tha
above, I would like to work
> with the maintainer to see the latest upstream version of "make"
> packaged in experimental, but for a while now the maintainer has been
> hard to reach.
I think it would be reasonable to let the MIA team know about Manoj's
protr
ady, I'm not too worried
> about it).
That part is apparently trivial, as I seem to have written a patch for it 4
years ago :-)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I ca
uld likely be: 1, 2, 3, 5, 4. (I could be persuaded to rank 4
above FD if this were the only way to move forward; but that's indisputably
the most disruptive to the archive, so I would hope we could reach agreement
that some or all of the other options are better.)
Cheers,
--
Steve Langasek
te this.
> As a medium-term solution it would be great if GNU make could itself
> support querying whether or not a makefile supports a given target.
> Since make needs to parse all the includes etc., only make itself can
> do this 100% reliably. If it's not already done
parator. Stop.
2
$
That's sufficient to let dpkg-buildpackage conclude "build-arch is not
supported", falling back to debian/rules build, without stirring up the old
arguments about whether we want to keep Policy 4.9.
--
Steve Langasek Give me a lever long enough and
ach is "impossible"
are equivalent to FUD.
> Proposal 3 is the safest approach,
It is the most error-prone.
--
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
eir debian/rules targets already for the second case
would get immediate benefit from autodetection, with no further changes.
--
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 Dev
ling files into
> > /lib64 and /usr/lib64 in packages with architecture amd64.
> Sounds sensible to me.
I agree.
--
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
of the sort), but have the license stanza contain the text of
LGPL-3? Or if that's not what you mean, could you please provide a concrete
example of the usage at issue?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set i
the upstream sources and letting users work out the
effective rights for themselves).
If someone cares about distinguishing between the upstream granted license
and the effective license, that's going to require much better tooling for
automating this than we have now.
--
Steve Langasek
lso wouldn't have a problem with it if the maintainer were to replace
'1.1' with '1.2' in the license declaration, fwiw.
I don't know whether a clarification in policy is needed to cover this. (I
don't think it's a syntactic question, so doesn't really be
y the "2 day" policy. Since this is contentious, I propose the
more conservative policy be applied, as per the attached patch.
Comments?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can mo
On Tue, Jul 26, 2011 at 12:21:48AM +0200, Bill Allombert wrote:
> Any offline discussion about policy should be ignored, as a matter of
> principle. If Lucas want to say something, he can just post it there.
He did, that's what I was referring to.
--
Steve Langasek
file [or text] there in the first place, if you're not
> going to read all of it?
Because not everyone who cares to know what rights they have to the software
knows what the MPL is (or has its terms memorized) in the first place!
--
Steve Langasek Give me a lever long
hat're meant
to be useful for *Debian* to make decisions.
Personally, if I've got a choice, I don't use licenses that are GPL
incompatible, eg, which the MPL certainly is.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ss or
on debian-policy makes no difference to me, but I for one am not happy to
see this integrated into policy as-is.
--
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
stream has weird opinions about such things)
> after asking the user to confirm this be allowed in Debian?
It would probably be allowed. However, it would still be buggy under
Policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
es will be given
preference, or that main packages will be given preference over non-free
ones, when resolving virtual packages?
In any case, you can't have versioned provides, so there are some use cases
where this would still not be sufficient.
--
Steve Langasek Give me a le
e language in 2.4 should be clarified to explicitly state this
only applies to modules from the perl source package.
--
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
dded to the insserv configuration file. We should
> either require init implementations to allow providing the standardised
> facility names or we should put that information somewhere in a a
> neutral location and format so all init implementations can make use of
> it.
Does
out without doing anything. Don't fight with init(8).
> ii. Even if an equivalent job file for another init system is
> available, the sysvinit script should behave as advertised (and
> not be a no-op) when init is sysvinit.
I agree that these are the relevant princ
I think merging such changes (which at a glance appear to include arbitrary
preferences of word choice) is a waste of everyone's time and I'm inclined
to ignore this altogether in favor of working on the real problems with the
text.
--
Steve Langasek Give me a lever lon
ing to spend overly long
discussing the options. Does anyone else have a preferred option that we
could quickly reach consensus on and enact?
I have a slight preference for:
GPL-2+ with OpenSSL and Font exceptions
because it's both easy to parse and reads natur
On Mon, Nov 14, 2011 at 07:24:21PM -0600, Jonathan Nieder wrote:
> Steve Langasek wrote:
> > I think merging such changes (which at a glance appear to include arbitrary
> > preferences of word choice) is a waste of everyone's time and I'm inclined
> > to ignore this
2.0-with-bison-exception does not mean that there is a
> special exception to use the GPL-2 with a so-called ‘bison’ license.
That has not been proposed.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
d we at the same time clarify
that if more than one exception is in use, you need to use a custom
shortname instead of an ORed or ANDed list of licenses.
Is there a consensus for this position?
I think for future versions of the standard, it's worth covering this case
ev
propose that the DPN editors won't relay them
> without at least an internal consensus.
Did you mean to post this to debian-policy? Debian-policy is the mailing
list for discussions of Debian's *technical* policy; you seem to be
discussing some other sort of political po
instead.
The GPL Font exception refers
to the text added to the license notice of each file as
--
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
On Sun, Nov 27, 2011 at 11:55:20AM +0900, Charles Plessy wrote:
> Le Sat, Jun 25, 2011 at 04:28:41PM -0500, Steve Langasek a écrit :
> > On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote:
> > > On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote:
r any of /run, /var/run, or /var/lock?
--
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com
rball.
> get-packaged-orig-source should be provided instead.
This is a bug filed against debian-policy, though, not against bzr-builddeb.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
U
uch as the MPL multiple times in a single file.
The second option is not acceptable first, because it's a substantial change
to the semantics of the DEP5 format, and that's not happening for 1.0;
second, because of the issue mentioned above about embedding logic in
parsers
hat's the intent at all. I think this is perfectly valid:
Files: *
Copyright: The Man in the Moon, 2007
License: GPL-2+ with OpenSSL exception
License: GPL-2+ with OpenSSL exception
This program is free software [...] as a special exception, [...]
On Debian systems, [...]
Perhaps the spec sh
aragraph with an extra Files: field.
I don't think that should be legal either however; we allow "extra fields"
to be added to any paragraph, but I don't believe the intent is to allow
*defined* fields to be used in paragraphs where they are not specified to be
permitted - only t
e top pointing at a url that lintian
doesn't know about, it would be reasonable to skip the rest and simply note
that an unrecognized format is being used. But when the file says it's
using DEP-5, it should be DEP-5.
--
Steve Langasek Give me a lever long enough and
r “additional
> fields”, but the current patch uses both. The Policy's chapter 5 uses
> “additional”, so this is where my choice would go even if it will increase
> the difficulty to search for previous discussions on the topic.
That's fair. Updated patch attached.
--
Steve
On Sun, Jan 01, 2012 at 09:58:45AM -0800, Russ Allbery wrote:
> Comments, objections, seconds?
Seconded.
Thanks,
--
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 Develo
d and make
> sure the text specifies it unambiguously but use plain text so as to
> make the changes not too invasive.
It would be nice to have a formal grammar down the line, but that's also too
large of a change for 1.0.
--
Steve Langasek Give me a lever long enoug
ime; but
some people might find it equally unpalatable to specify fields for
everything except git.
--
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
for
> that reason I think that it should be documented in the Policy.
Policy is for documenting what *SHOULD* be done. It doesn't matter if it's
10 or 1000 packages that are using Vcs-Git today; if the syntax is broken,
it shouldn't go in policy.
--
Steve Langasek
start job is available
> must query the output of the command initctl version for
> the string upstart and avoid running in favor of the native
> upstart job.
> I'd really like to see Policy provide some sample code for how to do that,
> since otherwise people are go
nt here. When upstart is installed, it
provides *commands* called "start", "restart", "reload", and "stop" in
/sbin. These are the commands that must not be called from maintainer
scripts. It has nothing to do with invocation of /etc/init.d/
scripts, whic
On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > I think you've misunderstood the intent here. When upstart is
> > installed, it provides *commands* called "start", "restart", "reload",
> > and &
uot;service" behave?
'service' is not a policy interface. Why do you want to make it one as a
precondition of letting people ship upstart jobs in the archive?
The answer, in any case, is that service should automatically prefer the
native jobs for whichever init is running, as this sh
tead.
I prefer the former because it respects policy's existing guidance about not
calling init scripts directly, but it also leaves a larger window when the
service will be down on upgrade - and the services that have bothered to use
'restart' in the postinst usually do so to pre
nfs-common.
I don't see any such hook script in nfs-common. I see a few hooks that
call *reload*, which is always safe to call regardless of any invoke-rc.d
or runlevel policy. But calling '/etc/init.d/$service start' directly from
a hook would be just as broken as calling i
the upstart discussion. Could we perhaps take this to the other
bug?
--
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 Developerhttp://www.debian.org
op as a fallback: how should invoke-rc.d handle the exit
code of /etc/init.d/foo?
All possible answers to that question are sufficiently irksome that I think
we should avoid putting the complexity in invoke-rc.d.
--
Steve Langasek Give me a lever long enough and a Free
ample if we expect the
init script to still handle the stop case, because the restart and
force-reload actions are so often implemented on top of start+stop.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I
he
> right place to put this logic imho. Putting it in each and every sysv
> init script on the other hand looks wrong to me.
You didn't actually answer the question I posed here. How should
invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in
the corner cases
, I don't think 'update-rc.d' is a sensible
tool to have as an admin-oriented, init-system-agnostic interface for
disabling services. 'service disable' would be much better.
--
Steve Langasek Give me a lever long enough
his.
There are really two subquestions here:
- When a package adds support for other init systems, how does it ensure
that the override status for the service is applied to all init systems?
- How should an admin disable a service to make sure it's disabled for all
ini
grant the tech commitee the authority to
> override the policy process.
Er, it most certainly does.
6.1. Powers
The Technical Committee may:
1. Decide on any matter of technical policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
tical issue.
Maintainer script calls invoke-rc.d foo stop. invoke-rc.d looks for a 'foo'
upstart job and finds none running. So it calls /etc/init.d/foo stop, which
fails.
Does invoke-rc.d return success because there was no upstart job running, or
failure because the init script fail
rrect agreement elsewhere.)
Attached is a corrected patch, which fixes the verb agreement issue above
and makes a few other tweaks (e.g., not introducing passive tense where it's
not needed, which is worse than the original problem it aims to fix), and
also catches a few more gender-specifi
eady exists and
> its parameters are sufficiently similiar to the parameters requested
> by the maintainer script.
How is "sufficiently similar" defined, and where is it documented? It's not
in policy, and I don't see anything in the adduser manpage that explains
this.
1 - 100 of 407 matches
Mail list logo
