On Tue, Oct 13, 2009 at 09:37:26AM -0400, The Wanderer wrote:
The question itself, in its starkest form, is simple.
Under what circumstances, if any, is it considered acceptable for a
package which is installed as a dependency by the upgrade of another
package to silently break the system?
On Tue, Oct 13, 2009 at 11:23:26AM -0400, The Wanderer wrote:
That's what I'd have thought, but I've run across a package which does
seem to do this, and the maintainer seems to consider it an acceptable
situation. Before trying to argue too much about that, I wanted to
confirm that it was in
On Tue, Feb 19, 2008 at 10:59:10AM +0100, Bas Wijnen wrote:
If we build separate infrastructure to test it, it would likely also try
to do this for every upload. And preferrably on different (or even all)
architectures we support. So if we make this whole extra check work
right, it isn't
On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote:
On Sun, Feb 17, 2008 at 09:29:59PM +, Mark Brown wrote:
On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote:
OTOH if the standard Debian build process jumps through unusual hoops
like forcing regeneration of all
On Mon, Feb 18, 2008 at 05:03:24PM +0100, Bas Wijnen wrote:
On Mon, Feb 18, 2008 at 12:47:41PM +, Mark Brown wrote:
On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote:
No, I don't want to force a version, I want the package to force it.
By forcing a version I mean doing so
On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote:
The fact that there exist packages which work properly without
recompiling from source doesn't mean it's a good default. IMO the
default should be to always compile from source. Yes, that means hassle
for the packager; it's pretty
On Sun, Dec 23, 2007 at 04:33:31PM -0500, David Nusinow wrote:
On Fri, Dec 21, 2007 at 05:00:15PM -0600, Manoj Srivastava wrote:
quilt is not even in the ball park. I am not sure it can play
the same ball game, even. I would love to see anyone try to convince
Linus how quilt
On Wed, Aug 22, 2007 at 12:07:50PM -0700, Ben Pfaff wrote:
One possible distinction is that in the Automake case, Automake
itself encourages distribution of convenience copies of parts of
itself. That is, it's the software that is copied, not the
software that is making use of the
On Sat, Nov 11, 2006 at 01:52:06PM +, Stephen Gran wrote:
I can imagine an argument for removing all of the intermediate files
(Makefile.in, configure, etc) in the clean target and rerunning the
autotools stuff from the build target. This would provide a relatively
small diff (provided
On Thu, Dec 29, 2005 at 01:39:01PM +0100, Marco d'Itri wrote:
To prepare for the eventual removal of makedev, I propose that packages
currently depending on it will add an alternative dependency to udev.
Also, policy should be amended accordingly.
It might be useful to tell the maintainers of
On Fri, Dec 09, 2005 at 12:57:28PM +0100, Teddy Hogeborn wrote:
And it's not like this would be changed on a running system, right?
It would just be the default value in /var/yp/Makefile for new package
installations for new NIS master servers.
That is not the case. /var/yp/Makefile is a
On Sun, Dec 11, 2005 at 04:54:17PM +0100, Teddy Hogeborn wrote:
Mark Brown [EMAIL PROTECTED] writes:
You might find that coming up with a concrete proposal for policy
might help there.
I have the feeling that all that would happen is that maybe someone
would ask the maintainers
On Fri, Dec 09, 2005 at 05:32:14AM +0100, Teddy Hogeborn wrote:
Mark Brown [EMAIL PROTECTED] writes:
This looks like a question for policy rather than the NIS package
since coordination with things like adduser seems at least desirable
so I'm reassigning the bug there.
Actually
package nis
reassign 329701 debian-policy
thanks
On Thu, Sep 22, 2005 at 11:25:38PM +0200, Teddy Hogeborn wrote:
(I tried to raise this question for general discussion some time ago
but no one replied. See
http://lists.debian.org/debian-policy/1998/10/msg00198.html.
Therefore I now submit a
On Tue, Dec 30, 2003 at 07:32:30PM -0500, Joey Hess wrote:
Mark Brown wrote:
Packages using debhelper appear to still use /etc/init.d directly.
Not really:
Yeah, sorry - I appear to have managed to pick on an older package to
check against.
--
You grabbed my hand and we fell into it, like
On Tue, Dec 30, 2003 at 10:18:18AM -0200, Henrique de Moraes Holschuh wrote:
On Tue, 30 Dec 2003, Dan Jacobson wrote:
not restart the services on package upgrades. Broken ones still calling
/etc/init.d/whatever directly will, but that's a bug: report it whenever you
find one of these
On Mon, Mar 24, 2003 at 11:55:23AM -0500, Ari Pollak wrote:
Nothing has been linked against libc5 for many Debian versions now,
why is libc6-migration.txt still included in the debian-policy package?
There's still at least one altdev package for libc5 remaining in the
archive (zlib1-altdev,
On Fri, Jan 17, 2003 at 11:26:01AM +0900, Atsuhito Kohda wrote:
For a configuration file which is very deeply system related
and sufficiently stable, it might be possible to satify the
current policy on configuration files but I suspect there are
many cases where an enhancement of an
On Wed, Oct 30, 2002 at 11:09:25AM +, Colin Watson wrote:
+ To avoid duplicate bug reports about missing manual pages,
+ you should inform the user that you know about the missing
+ manual page in
+ file/usr/share/doc/varpackage/var/TODO.Debian/file.
Why not just
On Mon, Jul 29, 2002 at 11:57:29AM -, Moshe Zadka wrote:
www-browser: definitely, here a standard interface (give a URL on the command
line) is useful. currently, urlview depends on an ugly hack
to do that (listing browsers itself)
You also need to know which
On Mon, Jul 29, 2002 at 02:30:15PM +0200, Wichert Akkerman wrote:
The same holds for editor which does have a well defined interface.
Well, quite. It's just that you need to put a bit more work into these
things than was being suggested.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Sat, Jul 27, 2002 at 09:28:56PM -0500, Branden Robinson wrote:
On Sat, Jul 27, 2002 at 09:20:03PM +0100, Mark Brown wrote:
It seems pointless given that you can't actually depend on the package
and expect it to do anything in particular - the package seems to serve
no purpose. I mean
On Sun, Jul 28, 2002 at 01:00:55PM -0500, Branden Robinson wrote:
On Sat, Jul 27, 2002 at 11:25:06PM -0400, Sam Hartman wrote:
all other) case. Perhaps something like DHCP clients compatible with
ifup/ifdown
dead in the water. I doubt that providing a description as you suggest
will do
On Sun, Jul 28, 2002 at 12:57:19PM -0500, Branden Robinson wrote:
On Sun, Jul 28, 2002 at 12:27:38PM +0100, Mark Brown wrote:
a mail transport agent ought to provide a /usr/sbin/sendmail
implementation
Only if policy says so. In and of itself this isn't a requirement
mandated by the fact
On Fri, Jul 26, 2002 at 11:03:05AM -0500, Branden Robinson wrote:
Do you formally object to the proposed update to the virtual packages
list?
It seems pointless given that you can't actually depend on the package
and expect it to do anything in particular - the package seems to serve
no
On Wed, Jul 24, 2002 at 08:59:12PM -0500, Branden Robinson wrote:
On Wed, Jul 24, 2002 at 12:48:43PM -0700, Matt Kraai wrote:
Suppose that no common interface is provided: if etherconf
doesn't know how to invoke udhcpc, then having udhcpc provide
dhcp-client will break etherconf's DHCP
On Thu, Jul 25, 2002 at 10:21:15AM -0500, Branden Robinson wrote:
Etherconf never invokes anything other than ifup and ifdown. It's ifup
that has the smarts. I know it already handles dhcp-client and pump;
i think (but may be wrong) that Branden has seen it work with udhcpc.
So what you're
On Fri, Dec 28, 2001 at 09:10:33AM -0800, Sean 'Shaleh' Perry wrote:
On 28-Dec-2001 Chris Tillman wrote:
That makes me uniquely qualified :-) to suggest some kind of
standardization for online help be implemented in policy for console
programs.
standards, everyone else just plays with
On Tue, Dec 11, 2001 at 10:48:52AM +1000, Anthony Towns wrote:
On Mon, Dec 10, 2001 at 09:56:51AM -0800, Ian Zimmerman wrote:
And is the overwhelming majority of interactive scripts that _do_ use
debconf already not a huge enough amount?
No, it's not current practice to use debconf when a
On Mon, Dec 10, 2001 at 09:22:09PM +1000, Anthony Towns wrote:
And thanks to this stupid MUST thing in policy everyone's wasting their
time trying to figure out how to force people to do things, instead of
making sure that there's absolutely no reason why they wouldn't want to.
Trouble is,
On Mon, Dec 10, 2001 at 11:41:50PM +1000, Anthony Towns wrote:
Sure there's something you can do: forward it on to -devel, try to make
sure it's clear what (if anything) the maintainer and you think the issues
are, and try to come to some sort of consensus about what should be done.
Of
On Mon, Dec 10, 2001 at 07:10:54AM -0800, [EMAIL PROTECTED] wrote:
Do you not agree that because of the reasons already identified, particularly:
* debconf is still relatively young
I'm talking about the general trend towards people wanting to put
everything sensible in policy irrespective of
When the discussion of this bug was happening in June it seemed that
there was a consensus that policy should be changed to require
notification about the creation of device files. Is the change in
policy actually going to happen?
I've now got one of the release critical bugs mentioned and feel
On Tue, Sep 04, 2001 at 11:28:15AM +0200, Eduard Bloch wrote:
Mark Brown wrote on Tue Sep 04, 2001 um 09:30:53AM:
MAKEDEV is a conffile.
Did I miss something?
cat /var/lib/dpkg/info/makedev.conffiles
/etc/init.d/makedev
No, I did. Sorry.
The discussion is about the requirement
On Mon, Jun 18, 2001 at 10:44:24AM +0100, Julian Gilbey wrote:
On Mon, Jun 18, 2001 at 12:13:58PM +1000, Anthony Towns wrote:
All conffiles are expected to be changed...
From 11.7.3:
The easy way to achieve this behavior is to make the configuration
file a `conffile'. This is
we want to discourage in
policy, or if I'm just not thinking the same way as most maintainers
(i.e. my premises are flawed).
I'd certainly not like to see this sort of message in stable. If we
ship it we should be willing to take responsibility for it.
--
Mark Brown mailto:[EMAIL PROTECTED
changelog entries like
that since before dinstall would close bugs for you. Seems to
completely miss the point of having a changelog, but there we are.
--
Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp
saying could be said (and has, on occasion, been
said) about Debian maintainers and upstream software.
--
Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
pgpZV9RAbiWjG.pgp
full path names for
binaries (I expect ls, grep, et al to be in the PATH, as they
should). I *NEVER* hard code the so called sbindir; and I think that
scripts should not, precisely for this reason.
What about configuration files and other data?
--
Mark Brown mailto:[EMAIL PROTECTED
before it could become
policy.
--
Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
probably
confuse as many people as it helped.
--
Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
pgpktaW9qXlzc.pgp
Description: PGP signature
a specific ordering would probably be overkill.
--
Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
pgp8ndAx5xLxu.pgp
Description: PGP signature
suggest themselves.
--
Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
pgpMBJUgo6jXG.pgp
Description: PGP signature
who aren't familiar with the
range of documentation formats used by Debian. It's also a lot
quicker than having man-db rebuild the index files only to tell you
it can't find anything.
--
Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk
44 matches
Mail list logo
