On Tue, 20 Jul 1999, Peter S Galbraith wrote:
> Manoj, you can't argue that all developers can quickly add a
> postinst script, and argue a few posts earlier that it will take 18
> months for all packages to get done. Can you?
He can. Please have a look at our BTS. There are many bug reports
pers
Maybe I can suggest an alternative which will
- not require packages to add anything to their maintainer scripts
- not break the majority of packages, and
- not create a forest of symlinks (which might be problematic, as has
been pointed out)
The dpkg-buildpackage program (and maybe autobuil
> Manoj, you can't argue that all developers can quickly add a
> postinst script, and argue a few posts earlier that it will take
> 18 months for all packages to get done. Can you? If it's so
> quick to do, why can't it be done quickly? I know I'll probably
> do my 7 packages in one sitting.
>
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
Chris> *purely* aesthetic objection, not a technical one
You are missing the point. It is not that users prefer one to
the other, the objection is that t
Hi,
I am working on converting the tasks and profiles from the base
installation into ordinary packages.
This will make the thing easier to manage, and offer these packages
also for later installation.
The packages constructing a profile will be pulled by a depends line
in the task package, and
Hi,
>>"Peter" == Peter S Galbraith <[EMAIL PROTECTED]> writes:
Peter> Manoj, you can't argue that all developers can quickly add a
Peter> postinst script, and argue a few posts earlier that it will take
Peter> 18 months for all packages to get done. Can you? If it's so
Peter> quick to do, wh
Hi,
>>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
Richard> That should be postinst and prerm, to stay out of dpkg's
Richard> way. If you remove it only in the postrm, then you will
Richard> break downgrades to pre-FHS versions.
I shall so amend the proposal.
Richard>
Hi,
>>"Kristoffer" == Kristoffer Rose <[EMAIL PROTECTED]> writes:
Kristoffer> Excuse me for asking a really silly question but I fear
Kristoffer> that we are overlooking the obvious in our enthusiasm for
Kristoffer> the complicated.
Enthusiam for the complicated? More like enthusiasm f
Richard Braakman wrote:
> This seems unnecessarily complex. You do not need to change the directory.
> I suggest (using absolute links while I'm at it):
>
>if [ -d /usr/doc ]; then
> if [ ! -e /usr/doc/$package -a -d /us
Dear all,
Excuse me for asking a really silly question but I fear that we are
overlooking the obvious in our enthusiasm for the complicated.
I tried to do the following on one of my slink systems:
# cd /usr/
# ls share/doc
ls: share/doc: No such file or directory
# mv doc share/doc
# l
Manoj Srivastava wrote:
> * The transition may take a long time, going by previous
> transitions, and not all packages are upgraded anywhere near
> simultaneously.
>
> I think that expecting _*all*_ packages to have moved before we
> release potato
Manoj Srivastava wrote:
> 3. Proposed solution
>
>
> I propose that there be a syymlink from /usr/doc/package =>
> /usr/share/doc/package, managed by the package itself. Since there is
> some concern that the packaging system does not deal well with
> repla
Hi,
Being too much work is not the only point, the point is that this work
would be quite useless.
There will be users who will like the symlinks, but there will be also
users who will dislike them (have we thought of them too?).
If a user likes the symlinks, he/she may create by himself/herself
On Tue, 20 Jul 1999, Julian Gilbey wrote:
> > You started this proposal, so why don't you simply bring it to a
> > good end? I'll support your intension...
> So I'd like some advice. The whole policy about /etc/rc?.d fails
> immediately when file-rc is being used. So should I actually propose
> a
On Sun, Jul 18, 1999 at 12:19:28PM -0500, Steve Greenland wrote:
> the /etc/init.d startup scripts as configuration files in any purest
> sense; they are more acurately described as "scripts subject to local
> modification" (which I personally would prefer be modified to store the
> configuration d
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> I would like you to elaborate on that.
I doubt that planning for a controlled transition is going to
slow the transition down. Not releasing potato cause we are still not
done and had not planned on the transition
Hi,
>>"Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:
Branden> On Fri, Jul 16, 1999 at 02:10:02PM -0700, Ben Gertzfield wrote:
>> If I remember, dpkg does not like replacing a directory with a
>> symlink. This may or may not still be the case.
Branden> Or vice versa.
Indeed
Hi,
>>"Stefan" == Stefan Gybas <[EMAIL PROTECTED]> writes:
Stefan> Joey Hess wrote:
>> # dpkg --print-avail libperl-
Stefan> I would also prefer such a scheme. What about colons in
Stefan> package names?
Illegal, since we intriduced epochs.
Stefan> I know that they are currently
On Mon, 19 Jul 1999, Darren O. Benham wrote:
> No reason but "ease". If you, we, the ftpmasters want to do a
> data/[main|contrib|non-free] on the same level as our current
> [main|contrib|non-free] that's ok with me. That DOES give us trees like..
Not to mention it looks like the non-us struc
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> But your proposed solution creates an inmense lot of work
Santiago> for everybody, just to keep compliance with a standard
Santiago> (FSSTND) which is not the one that we should follow. Every
You have a strange def
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> This is a high price to pay, very high.
Adding a stanza to a couple of files too high a price to pay?
Your solution ignores all the points made in the proposal:
* The transition may take a long tim
Ups.. I haven't read the constitution yet... =)
May I second this proposal or I need a special hat? (I hope not a red one).
On Mon, Jul 19, 1999 at 10:55:57PM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Darren" == Darren O Benham <[EMAIL PROTECTED]> writes:
>
> Darren> I would say only DFSG data. Anything on our ftp site needs
> Darren> to have unrestricted redistribution, really, so that we don't
> Darren> have to m
> > Create the symlink in post inst. dpkg need not be involved.
> Ah, but then this is not a simple one-line addition, as you said.
> For most of my packages, I have to change just one line in debian/rules
> to be FHS-compliant. With your proposal, the amount of work is not doubled
> by may
Hi,
>>"Darren" == Darren O Benham <[EMAIL PROTECTED]> writes:
Darren> I would say only DFSG data. Anything on our ftp site needs
Darren> to have unrestricted redistribution, really, so that we don't
Darren> have to make any checks or put ourselves at risk
Why do we need any rules
On 19-Jul-99, 04:25 (CDT), Julian Gilbey <[EMAIL PROTECTED]> wrote:
> One other question about the proposal. Is it necessary for multiple
> packages which share a configuration file for one of them to specify
> it as a conffile? Maybe it is a configuration file which by nature
> cannot be a conf
-BEGIN PGP SIGNED MESSAGE-
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc'
[...]
> During the transition, we need to provide backwards compatibility,
> firstly for programs ike `dwww', and `dhelp', and also for our users
>
[Cc'd to -policy for comments.]
> > > So I (as the actual maintainer of file-rc) second your proposal, to
> > > change the policy in a way, that forbids to create the symlinks in a
> > > way different to update-rc.d.
> >
> > Should I undertake to propose a revised wording or would you like to?
>
On Fri, Jul 16, 1999 at 02:10:02PM -0700, Ben Gertzfield wrote:
> If I remember, dpkg does not like replacing a directory with a
> symlink. This may or may not still be the case.
Or vice versa.
I can attest to this. This little landmine blew up in my face about 100
times while I was reorganizing
29 matches
Mail list logo
