Previously Raphael Hertzog wrote:
> And it's the second part that we want to change in order to allow
> non-interactive installation. But if we do not clearly
> separate the first part from the second the only way of
> non-interactive install will be to use the configuration database.
Of course n
Manoj Srivastava writes ("Re: FHS - transition") [1]:
> "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
> > My scheme:
...
> > * [list of bullet points snipped]
>* Needs a flag day for the transition
To my mind, a flag day is a point in time when the entire universe
must change simultane
Hi,
>>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:
Steve> On 20-Oct-98, 11:48 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> The one exception is seeding files for root. Since /root is is
>> already created by the base, and it may have special needs for
>> startupo files (lik
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> Maybe you are simply surprised by the fact that base-files recently
Santiago> changed from installing a default /root/.bash_profile to installing a
Santiago> default /root/.profile (which is slightly "more POSIX").
Santia
On Thu 22 Oct 1998, Adam P. Harris wrote:
> Paul Slootman <[EMAIL PROTECTED]> writes:
>
> > If policy is changed that for portability issues immediate "normal"
> > NMUs are permitted, then I'd have no problem in doing this.
>
> Well! I have no problem getting policy changed to include this
> cla
Joey Hess wrote:
>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
> Hmm, I usually keep my current version of the sources of my package
> locally. It's a small effort to implement any diffs submitted to the
> BTS to my development version in any case. So, I don't think that "a
> sourceful NMU takes away the sources under his feet" is applicable.
But many people
Paul Slootman <[EMAIL PROTECTED]> writes:
> They are currently "necessary" because of the mandatory waiting
> period between filing a bug and doing a "normal" NMU (i.e. with
> source). It's not manageable for porters who do dozens if not
> hunderds of packages to keep track of all of this.
> If p
On Thu 22 Oct 1998, Roman Hodek wrote:
>
> > If policy is changed that for portability issues immediate "normal"
> > NMUs are permitted, then I'd have no problem in doing this. The
> > point is that currently it is _not_ policy, and I'd invoke the wrath
> > of those developers who don't immediatel
> If policy is changed that for portability issues immediate "normal"
> NMUs are permitted, then I'd have no problem in doing this. The
> point is that currently it is _not_ policy, and I'd invoke the wrath
> of those developers who don't immediately understand the problem,
> and who subsequently
On Wed, 21 Oct 1998, Steve Greenland wrote:
> Here are some problems with the current "solution":
>
> 1. Who said that root's home dir is /root?
The /etc/passwd file as provided by base-passwd. If you modify root's home
dir, you break the base-passwd package, since root is a user who belong
to t
> Finally, I'd like to hear for any listening porters (Roman?) about
> why binary-only NMUs are a necessary part of their porting workflow.
> I understand they are simply a lot faster to produce in cases where
> minor, interactive style hacking is required on a package.
First to clear up a misund
On Thu 22 Oct 1998, Adam P. Harris wrote:
>
> Finally, I'd like to hear for any listening porters (Roman?) about why
Paul OK? :-)
> binary-only NMUs are a necessary part of their porting workflow. I
> understand they are simply a lot faster to produce in cases where
> minor, interactive style h
In article <[EMAIL PROTECTED]>,
Martin Schulze <[EMAIL PROTECTED]> wrote:
>Miquel van Smoorenburg wrote:
>> sh script.sh is very different from running it in a subshell with ().
>> For example, bash doesn't really fork a new invocation - it just
>> sets up a new internal environment temporarily. I
Well, the discussion is raging on. Let me try to summarize, since I'm
the poor schlub who has to try to document all this in the Developer's
Reference.
First off, full compliance with the licensing of packages under GPL
and MPL and other "keep source available" licenses (which BTW
constitutes th
In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>> "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 p
On 20-Oct-98, 11:48 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> The one exception is seeding files for root. Since /root is is
> already created by the base, and it may have special needs for
> startupo files (like, it needs to be way more secure), the files in
> /etc/skel are not used
On 20-Oct-98, 05:22 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
> 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").
No, I just noticed because I
> > Shouldn't we create with all this a `Linux registry' (sorry, but the
> > structure is very similar to the Windows one).
> > The `Linux registry' would be offered, through an API, to software
> > developers and other distributions, so there would be softeare enterely
> > configured with this r
19 matches
Mail list logo
