Manoj Srivastava wrote:
I would not want this to change. Anyone can make innovative
proposals, but the hard part is getting things to work -- and just
doing it. Debhelper, debconf, the whole testing distribution -- were
all proposed, and worked on, without first getting policy to ble
On Tue, Sep 02, 2003 at 08:09:18PM +0200, Josip Rodin wrote:
> And how do you suppose this consensus thing works if you can't get a
> consensus over the said policy changes? I sense a grave misunderstanding...
It doesn't work, you'll never get a consensus with over 1000
developers. That's why I'd
Josip Rodin wrote:
Sorry, I lost you there. Is that to make us believe FHS transition was
proper or improper, necessary or unnecessary, or what? :)
No, I only wanted to show that it has been impossible the get major
Policy changes accepted in the past 4 years. It's not that there haven't
bee
Manoj Srivastava wrote:
So from now on, we'll only change Policy after all packages comply
with the proposed changes?
Yes. This is how policy has always worked; too.
Maybe in most cases, but I think not in all cases. Counter examples are
the move from FSSTND to FHS in Policy 3.0.0 (
[Directly answering to -policy, this does not need to be archived in the
BTS.]
Henrique de Moraes Holschuh wrote:
Tested patches against all init-script using packages to the BTS.
So from now on, we'll only change Policy after all packages comply with
the proposed changes? We'll never make
Andrew Suffield wrote:
You can't make it mandatory before you implement it.
I'll implement "status" for the init script and the changes to the
maintainer scripts in my packages with the next upload. What else should
I implement?
Stefan
On Mon, Sep 01, 2003 at 10:58:50AM +0200, Martin Godisch wrote:
> Attached an updated proposal, without exit code 5 clause.
I second this updated proposal.
I think status should be mandatory so it could be used by maintainer scripts
on package upgrades. This way, a service would not be started i
From my mail to debian-java
(http://lists.debian.org/debian-java/2003/debian-java-200307/msg00054.html):
I don't think it makes sense. Sure, packages that contain webapps can
depend on "java-servlet-engine" and put their webapp in
/usr/share/java/webapps. But how do they tell any arbitrary ser
ses with kaffe/classpath (and Debian would surely prefer
to use free tools to compile packages).
--
Stefan Gybas
Adam Heath wrote:
> libapache-mod-jserv stored data into /etc/apache
Yes, but it also depended on apache so you could not remove apache without
breaking dependencies.
--
Stefan Gybas
eeks ago (see
http://www.debian.org/Lists-Archives/debian-policy-9909/msg00240.html)
which does not have this problem.
--
Stefan Gybas
kage (and now an
additional symlink in /usr/share/doc/ to /usr/share/doc/$package).
So what is the exact reason why you think this will not work?
--
Stefan Gybas
symlink (to another directory in /usr/doc).
--
Stefan Gybas
remaining files
in /usr/doc/package to /usr/share/doc/package?
--
Stefan Gybas
c/
directory (if it is empty) in the postinst?
--
Stefan Gybas
needs the real lpr to build, so you can't just
say Build-Depends: lpr.
I'll accept any choice for the other open points, so I hope we'll get
a consensus and accept the proposal (the sooner the better).
--
Stefan Gybas
lprng example
convinced my that Build-Conflicts: is needed so I'm changing my opinion
here.
--
Stefan Gybas
About the conflict headers: I don´t think they are necessary, so
I vote for removing them from the proposal (as Richard suggested).
About 4 or 6 fields (actually 2 or 3 without *-Conflicts:): Both
models are fine for me, I prefer the one with 3 fields.
--
Stefan Gybas
Antti-Juhani Kaijanaho wrote:
> And I'm still looking for another second.
I second this proposal.
--
Stefan Gybas
Was this changed when epochs were
introduced?
We could then name perl packages like perl-xml::cgi, perl-net::dns and
perl-uri, so a search for "xml::cgi" would find the correct package.
--
Stefan Gybas
an-up proposal
> (#40767) are currently stalled with only one official seconder (Joey
> Hess).
I second both proposals.
--
Stefan Gybas
Hamish Moffatt wrote:
> inetd.conf is _not_ a conffile.
Ok, now I understand. In a previous mail you once wrote "conffile"
when you probably meant "configuration file which is not a conffile" and
this was causing somy of my confusion. Sorry for this!
--
Stefan Gybas
the reason for such a program then?
This looks like the only clean solution would be to provide update-*
programs and not to mark the configuration files as conffiles. But this
means that update-* programs should not modify conffiles at all.
--
Stefan Gybas
ied configuration
file in both cases. So what should I do? Let the user do the changes to
the configuration files? Ask a lot of questions in the postinst? IMHO the
automatic setup in the postinst is a very user friendly solution.
--
Stefan Gybas
Roland Rosenfeld wrote:
> If there really is a technical problem with this link as mentioned by
> Santiago (I didn't check this myself), we can handle this symlink in
> postinst:
I second this proposal (I mean the whole symlink proposal, not just this
addition).
--
Stefan Gybas
25 matches
Mail list logo
