Hi,
*This is opinion*.
I would not have expected the init.d scripts to be generally
sourced by rc, and woud be surprised not to have them regular
standalone scripts (I often call them manually, as in
# /etc/sendmail reload)
So, I, for one, would prefer them to be sta
In article <[EMAIL PROTECTED]>,
Martin Schulze <[EMAIL PROTECTED]> wrote:
>In /etc/* there are severeal scripts that are named *.sh. Most of
>them are not marked executable and don't contain a "#! /bin/sh" line.
>
>Thus, to run them you need to "sh foo.sh" or "source foo.sh" them.
>This raises a
Hi,
i've just subscribed to -policy but I read some mails in the archive about
configuration management. The configuration management thread has started
with the need of a non-interactive installation process, I believe.
We are now talking about a big registry containing the informations needed
f
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> The purpose of shipping the docs in binary packages is to
Santiago> made them available to be read, not to be printed.
And the purpose of the proposed change to Policy is that the
documentation be available in a fo
In /etc/* there are severeal scripts that are named *.sh. Most of
them are not marked executable and don't contain a "#! /bin/sh" line.
Thus, to run them you need to "sh foo.sh" or "source foo.sh" them.
This raises a problem if the script contains code like "test -x foo ||
exit 0". This would ca
Hi,
>>"Adam" == Adam P Harris <[EMAIL PROTECTED]> writes:
Adam> [ BTW, I don't think this group should be maintaining the
Adam> Packaging Manual, but I don't volunteer for that job... ;) ]
Slow as it maybe, I still think this group is the correct
owner of contents of the Packagingn m
On Tue, Oct 20, 1998 at 07:07:03PM +0200, Santiago Vila wrote:
[About DVI]
> (BTW: What font issues are you talking about?)
DVI is not a self-contained format. It does not include font data, it
only refers to fonts (as in, "select cccsc10" when ten-point Concrete
Small Caps is requested). So, in
On 20 Oct 1998, Manoj Srivastava wrote:
> Santiago> It seems to me that the general rule that source belongs to
> Santiago> the source package should apply here.
>
> No. HTML is not a good format for printing. dvi files are not
> quite as portable as one would like (due to font issues)
On 20 Oct 1998, Manoj Srivastava wrote:
> Santiago> So shipping the .texi source will not be as easy as some
> Santiago> people think,
>
> And not as hard as some people think either.
He, he, we are close to repeat the bash-essential discussion here ;-)
--
"8460b24dc2ac9d46432ccd89653
Hi,
>>"Martin" == Martin Mitchell <[EMAIL PROTECTED]> writes:
Martin> I think packages should generally leave home directories
Martin> alone, however it's reasonable that required packages like
Martin> base-files may install some files to provide some sensible
Martin> defaults, if they do not
Hi,
In general, packages should not install files in user
directories, and this includes root, with one exception. However,
one should also realize that user home directories may need to be
seeded with files at initial creation, and there is a mechanism for
that. The mechanism is /etc
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> Some people propose that we ship .texi source in binary
Santiago> packages, but this means that we would have to identify
Santiago> *all* those extra files that are needed to generate the
Santiago> .html. This is a lot of
> That's right. This could be done occasionally out of cron, though.
> There's no harm in extra old source packages hanging around for a
> bit.
Ok.
> No, I don't think so. The FTP site and the BTS are definitely not
> the `same place' according to the GPL. For this to be true we'd have
> to make
> > Perhaps we should relax this policy, then.
>
> I tend to agree. The wait seems to be the crux of the problem. Perhaps we
> could let porters make NMU's with no wait at all?
This would be helpful in some cases, but doesn't solve the problem
that other archs have to recompile that NMU version,
( Sorry for replying so late, the old Subject was not very appealing :-)
On 23 Sep 1998, Manoj Srivastava wrote:
> I suggest that the preferred source format of the
> documentation be also available. This means that we also ship
> texinfo, tex, and sgml versions of the documentation, as w
> Since we cannot rebuild for all architectures simultaneously and do
> not want to withdraw binaries or wait with porting,
> *we MUST be able to have more than one source version in our archive*.
[...]
> i. Simply have them side by side, with some kind of way of making
> obso
Ian Jackson wrote:
> Interesting point, yes. However, I think we need to fix the source
> skew problem now, and it's relatively easy: fix dinstall not to delete
> sources, and run a cron job occasionally to delete obsolete ones.
It is not quite so easy. Sometimes different revisions of a source
Hi.
Maybe you are simply surprised by the fact that base-files recently
changed from installing a default /root/.bash_profile to installing a
default /root/.profile (which is slightly "more POSIX").
I considered several ways to do this. Among them:
1. If ~/.bash_profile exists and ~/.profile doe
On 17 Oct 1998, Adam P. Harris wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
> [...]
> > They are not just "things that would be nice to have implemented"
> > (wishlist). We really *need* to have them fixed in the near future.
> > Otherwise we will never move to FHS.
>
> Woah there, one step
On Mon, 19 Oct 1998, Ian Jackson wrote:
> Are the additional things I said in my last message about this
> sufficient for you to clarify the policy ?
I think they are not sufficient.
Maybe I should propose an amendment to the current text.
--
"3bfc2ca36032b30f1040093bfee1f3ea" (a truly random
Steve Greenland <[EMAIL PROTECTED]> writes:
> The current base-files installs a default .profile and/or a default
> .bashrc in /root if there is no existing instance. I filed a bug, but
> the maintainer (Santiago Vila) closed it with the following message:
>
> > [explanation of why *snipped*] I b
On Mon 19 Oct 1998, Ian Jackson wrote:
> I wrote:
> > [...] there's no harm in a small amount of version skew at release time.
>
> Several people have misunderstood this; my apologies for being
> unclear.
>
> I meant that there is no harm if the binary versions for (say) m68k
> and i386 are slig
On Mon 19 Oct 1998, Ian Jackson wrote:
> Paul Slootman writes ("Bug#27906: PROPOSED] Binary-only NMU's"):
> ...
> > If you're saying that each and every binary version should be accompanied
> > with corresponding source only when a release is made, then the whole
> > problem could be circumvented b
Ian Jackson wrote:
> > Current policy is to ask the maintainer first and wait some time with
> > the NMU, except if it's really urgent (security stuff or so). But this
> > is often too long, which is one reason why we make bin-only NMUs.
>
> Perhaps we should relax this policy, then.
I tend to ag
Adam P. Harris wrote:
> It doesn't. But the Packaging Manual *does* have something to say
> about setuid files:
>
> 3.4.1. Restrictions on objects in source packages
> -
>
> The source package may not contain any hard links[1][2], device
>
In article <[EMAIL PROTECTED]>, Ian Jackson <[EMAIL PROTECTED]> writes:
> Adam P. Harris writes ("Bug#27906: SUMMARY of Bug#27906: [PROPOSED]
> Binary-only NMU's "):
>> If this topic under discussion is a proposed correction to the
>> devel-ref, we should refile the bug accordingly. I would be
>>
In article <[EMAIL PROTECTED]>, Joey Hess <[EMAIL PROTECTED]> writes:
> I don't understand why the docs say to put in the chmod too. I
> guess so long as you have the chmod in there, it doesn't matter if
> you make the .deb file actually have the suid bit set in it or not -
> I tend to go ahead and
(While this relates to a specific package, I think my real question
is more policy related...)
Can a package install files (via the unpack or a package maintainer
script) in a user directory? (I'm not talking about something trn or
netscape that creates one or more "user-state" files when it is ru
Branden Robinson wrote:
> Well, I was just following the example set in sendmail.
>
# manage setuid X binary
> if [ -x /usr/sbin/suidregister ]; then
> suidregister -s xserver-common /usr/X11R6/bin/X root root 4755
> else
> chmod 4755 /usr/X11R6/bin/X
> fi
The above is fine, it is how suidmana
On Mon, Oct 19, 1998 at 07:21:35PM -0700, Joey Hess wrote:
> Branden Robinson wrote:
> > > 3) The server no longer is setud root. Thus it refuses to come up at all.
> > > 4) startx only comes up under root (some authority problem).
> >
> > I'm now using suidregister to make /usr/bin/X11/X (which
30 matches
Mail list logo
