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
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
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
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
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
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
[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
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
does not have this problem.
--
Stefan Gybas
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
was a
symlink (to another directory in /usr/doc).
--
Stefan Gybas
(if it is empty) in the postinst?
--
Stefan Gybas
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
.
--
Stefan Gybas
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
. 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
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
seconder (Joey
Hess).
I second both proposals.
--
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
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
20 matches
Mail list logo
