> >> >>"Brian" == Brian White <[EMAIL PROTECTED]> writes:
> > The original conversation I had waaay back with the webserver guys
> > is that they wouldn't go ahead with these changes until it _was_ official
> > policy. If you r
> >>"Brian" == Brian White <[EMAIL PROTECTED]> writes:
>
> Brian> Okay... This has been approved and passed all the stages.
> Brian> Would somebody please make the change to the official policy
> Brian> manual so we can move ahead?
>
>
Okay... This has been approved and passed all the stages. Would somebody
please make the change to the official policy manual so we can move ahead?
Thanks!
Brian
( [EMAIL PROTECTED] )
--
> > Have we decided on whether aj's proposed changes (below) are
> > what we reached a consensus on?
> > ==
> > /usr/lib/cgi-bin/
> >
> > ~wwwdata/cgi-bin/
> > > postinst
> I don't see any value to letting the guy browsing your website be able
> to tell the difference between local CGI scripts and remote ones though.
> It seems beneficial not to, even, so you can have replace your homebrew
> build of http://example.com/cgi-bin/analog with the prepackaged version,
>
> >> Yes. But the scripts still live in ~www-data/cgi-bin, right?
> >> If not, I missed when you are going to have packages move the scripts
> >> out.
>
> Brian> All system scripts would live under /usr/lib/cgi-bin and be
> Brian> accessed via /cgi-lib. To make for a smooth
> Brian> transit
> > > What would y'all think about having cgi-bin managed more like, umm:
> > > /usr/lib/cgi-bin/
> > >
> > > ~wwwdata/cgi-bin/
> > > > > postinst,
> > > based on some setting in /etc/ somewhere>
> > This has how I've done my site,
> > > Perhaps things have changed in the last 3 years, and they
> > > shall understand that post the /usr/doc issue policy has become more
> > > conservative?
> > I'm afraid I don't understand what you mean here.
>
> He means the best way to get something in policy is for it to be
> impl
> Brian> Once it becomes official policy, then I can get them to make the
> Brian> necessary changes. And once the webservers begin to change over,
> Brian> then I can get the packages to change.
>
> Perhaps things have changed in the last 3 years, and they
> shall understand that pos
> Brian> What is the next step in moving this in to being official
> Brian> policy? I was told I couldn't request any changes to the
> Brian> various webservers until it was accepted as such.
>
> Quite the contrary. Policy documents current, working
> solutions. We should not make pol
(First I get one address wrong, then the other.3rd time...)
What is the next step in moving this in to being official policy? I was
told I couldn't request any changes to the various webservers until it
was accepted as such.
===
> The update-mime program seem to convert %s in /usr/lib/mime/packages/
> files into '%s'. This seems to be a Bad Thing. Applications using
> mailcap must escape filenames before the execute the command
> themselves. Reason: how would you handle a filename containing the
> character ' otherwise?
> > Any idea when the patch I provided will actually be applied to the policy
> > manual? It would be nice to get this underway. Thanks!
>
> Policy is frozen.
I realize that. Any idea when the patch I provide will actually be applied
to the policy manual? It would be nice to get this underway
Any idea when the patch I provided will actually be applied to the policy
manual? It would be nice to get this underway. Thanks!
Brian
( [EMAIL PROTECTED] )
---
Now that we're getting ready for a new release, I'd like to implement
this new policy in the new development stream. Here is the text I plan
to include in the necessary bug reports I'll submit.
I don't forsee any difficulties with the upgrade path. Please let me
know if you think I missed someth
> Brian> This this has now passed the first step of a policy change,
> Brian> I'm changing the bug title and severity. Sorry for the
> Brian> delay... I hadn't realized what I had to do.
>
> The one problem I see with this proposal is that it does not
> put into place any transition
retitle 32263 [AMENDMENT 20/01/2000] Splitting cgi-bin
severity normal
--
This this has now passed the first step of a policy change, I'm changing
the bug title and severity. Sorry for the delay... I hadn't realized
what I had to do.
> -
> Most people setting up a web site expect /cgi-bin/
> On Thu, Nov 02, 2000 at 09:16:02AM -0500, Brian White wrote:
> > -
> > Most people setting up a web site expect /cgi-bin/ to be available for
> > scripts on their site. Unfortunately, Debian uses this for those scripts
> > packages that get installed. These
Now that there is some time to make changes before the next release,
can we look at this idea again. It's really a pretty simple idea
that would save some headaches for professional webmaster. Most
people have said they thought it was a good idea. It just needs to
go through the final steps of b
reopen 32263
--
How about waiting just a bit longer? I was going to try to start this
again when (if?) the release happens. Numerous people have thought it
was a good idea, but there have been more important things on the plate.
Brian
> I'd like to re-open discussion on a proposal I made some time ago. The
> current policy on the setting of "cgi-bin" tends to interfere with how most
> webmasters set up their sites. Most people setting up a web site expect
> /cgi-bin/ to be available for scripts on their site. Unfortunately, D
> > Goal of this proposal
> > =
> >
> > I'd like to see MIME support become as successful as menu support, and
> > therefore I'm proposing the addition of a MIME support sub-policy.
>
> Seconded.
Thirded. (As maintainer of the mime-support package, I might as well add
my supp
> > As such, I think Debian's system should be altered a bit. I recommend using
> > instead the name "/cgi-lib/" for scripts under /usr/lib/cgi-bin/. This
> > will keep both features independant and not affect the general use of
> > the system.
> >
> > More information about this as well as some
I'd like to re-open discussion on a proposal I made some time ago. The
current policy on the setting of "cgi-bin" tends to interfere with how most
webmasters set up their sites. Most people setting up a web site expect
/cgi-bin/ to be available for scripts on their site. Unfortunately, Debian
u
Hi!
This was a change I proposed quite some time ago (not Johnie Ingram as
reported in the debian-policy logs). It's status has been changed to
fixed (rejected), but I have been able to find no discussion of it either
on the bug report or in the debian-policy mailing list archives. Would
somebod
> > A priority change is not changing "too much", it does not require to
> > compile any package, and it does not make the package to be in another
> > section (i.e. another directory), so not even automatic upgrade scripts
> > would be confused about it.
>
> I agree with you. (Wow, you should ma
> > > Sure, the scripts will move and they will still work in and of
> > > themselves, but what about all the hard links from webpages on their
> > > site to scripts in /cgi-bin that are debian cgi scripts installed by
> > > packages. If we suddenly change it to /cgi-lib then links to all the
> > >
> > What will break most is packages that use /usr/lib/cgi-bin, and they can
> > be fixed before the next release of Debian so as to make the entire
> > transition appear seamless.
>
> Sure, the scripts will move and they will still work in and of
> themselves, but what about all the hard links fr
> I don't see this pertaining to cgi's. With the /usr/local convention it
> doesn't require any extra effort to use the programs (just add
> /usr/local/bin to PATH) but with a cgi-bin/cgi-lib seperation you will
> have to make two distinct calls to different URL's in order to call Debian
> cgi's an
> > Most people setting up a web site expect /cgi-bin/ to be available for
> > scripts on their site. Unfortunately, Debian uses this for those scripts
> > packages that get installed. These two need to be independant.
>
> I don't seem to understand your intention. Why to you want to separate
>
> > > More info than what we have now w/ nags would be VERY much appreciated.
> > > As
> > > will the 1 mail thing.
> >
> > What more information would you like to see?
>
> Generally what the bug is for one. Those that you sent and I saw in the
> -policy list didn't really tell you anything abo
> > I would be happy to comply with your request except that it no longer
> > has any basis. You complained because you received "hundreds" of
> > unrequested emails. That will never happen again. So why do you
> > continue to complain?
>
> Dale is completely within his legal rights to request
> > > More info than what we have now w/ nags would be VERY much appreciated.
> > > As
> > > will the 1 mail thing.
> >
> > What more information would you like to see?
> >
>
> 1. A synopsis of the bug log. In particular, any suggested solutions.
>
> 2. Clear examples that exhibit the bug.
>
>
> I don't care that you "don't want to remove people". This is unsolicited
> spam and I want you to stop sending it to me.
This is untrue and you know it. You're registered as a Debian developer
and all the perks/requisites that come with it.
Brian
> More info than what we have now w/ nags would be VERY much appreciated. As
> will the 1 mail thing.
What more information would you like to see?
Brian
( [EMAIL PROTECTED] )
-
> This is a formal request for removal from the NAG distribution list.
>
> Receiving 100 useless messages, each indicating an outstanding bug, is the
> worst kind of spam. It imparts no information, either about the bugs, or
> any suggested fixes. It only adds useless mail to my inbox, which I mus
severity 23000 normal
--
> The reason that sendmail broke is that you made a DELIBERATE modification
> to procmail that sendmail wasn't expecting. While I agree that sendmail
> should probably be more graceful about handling it, it is not a
> release-critical error. A vast majority of people (li
It is policy that package that depend on non-free packages must go into
contrib. However, what if a package depends on a virtual package that
is only provided by packages outside of "main"?
This came up in Bug#16652 where "javalex" depends upon "java-virtual-machine"
but that virtual package is o
> > > Noone may submit many bug reports or send mail to many maintainers
> > > without prior approval for the specific person in question to send
> > > mail under those specific circumstances.
> >
> > approval from whom?
>
> Several people already have "mass mailer" scripts (bcwhite, Christian,
> > Non maintainer releases do not close bugs. However, a non maintainer
> > release that *just* fixes a bug because a bad building environment
> > (buggy debstd, in this case) should probably be able to close such
> > bugs. What do others think about this?
>
> Just downgrade the severity of the
> 1) The bug server takes care of reminding maintainers that have packages
>with old unattended bugs. Everyone knows that there are old bugs open.
>There is no need to send reminders without additional information specific
>to the bug. Therefore, sending reminders to a bunch of old bu
> I propose the following policy:
>
> No package shall create without approval any command name (or
> corresponding manpage):
>
> 1. not matching the regexp ^[a-z0-9]..
> 2. matching ^... if it creates more than two such
> 3. matching [^-+._,a-z0-9], or
> 4. which is a single common dictionary wo
> Umm, did you even read the FHS before posting this? /usr/share is
> mandated by FHS
I knew it's purpose, yes. The only thing that this mentions that I didn't
know is the "is for all read-only architecture independent data files" part.
I can understand why making it untouchable by packages wil
I'm finding that I really dislike having packages put things in /usr/share.
1) If /usr/share is a read-only mount, then I have to unmount it. This means
that all the files under /usr/share still get installed on my machine even
if I'm mounting that directory from elsewhere. (I can delete t
> You _will not_ persuade me to abandon this. If you make it mandated
> policy that I only have one email address I shall simply ignore you.
Come on Ian, what kind of attitude is this? I sure everyone can think
of things in the "policy" that they don't like. I find this type of
remark to be sim
> > > > The current policy does not allow packages to touch /etc/crontab
> > > > anymore. This is because we don't allow packages to modify other
> > > > packages configuration files.
> > >
> > > We should also correct the policy to say that _no_ package should touch
> > > _any_ config file from a
> > One of the release goals for Debian 2.0 has been to link all shared
> > libraries dynamically against each other. This can be done by using the
> > `-lc' option when linking the library. With that, the library will contain
> > valuable dependency information about which other libraries the libr
> If bash is invoked with the name sh, it tries to mimic the
> startup behavior of historical versions of sh as closely
> as possible, while conforming to the POSIX standard as
> well.
>
>So, if POSIX says that the example above should be
>
>$
> > The current policy does not allow packages to touch /etc/crontab anymore.
> > This is because we don't allow packages to modify other packages
> > configuration files.
>
> We should also correct the policy to say that _no_ package should touch
> _any_ config file from a script. The problem cau
> > If a program should depend on environment variables for its
> > configuration, the program has to be changed to fall back to a
> > reasonable default configuration if these environment variables are
> > not present.
>
> My counter example here would be Oracle. That relies on environment
> On Tue, Jan 13, 1998 at 11:34:21PM +0100, Christian Schwarz wrote:
> > Restrict your script to POSIX features when possible so that it may
> > use /bin/sh as its interpreter. If your script works with ash, it's
> > probably POSIX compliant, but if you are in doubt, use /bin/bash.
>
> DEBIAN POLICY WEEKLY, #5 (January 13, 1998)
I don't know what "states" proposed policies have, but I think it would be
a good idea to add "tested" at the end of the list (if it's not already
there). This state would mean that the policy was tested for _automatically_
on all packages either peri
> With the policy on POSIX shells coming up, would a virtual package `sh',
> or `posix-shell', be appropriate? I think bash and ash could provide it,
> and possibly others, too (ksh? zsh?). I also think the link /bin/sh could
> be perfectly managed by the `alternatives' system, with the `smallest'
> However, both FSSTND and FHS are very clearly state:
>
> /usr/src :
>
> [...]
>
> Any non-local source code should be placed in this subdirectory.
>
> IMHO, /usr/local/src is the place for the sysadmin, /usr/src is the place
> for packages.
Agreed.
> > I also think the
> > link /bin/sh could be perfectly managed by the `alternatives'
> > system, with the `smallest' shell (in terms of memory and processor
> > requirements) having the highest priority.
>
> How about "most standard", i.e., most in accordance w/ POSIX? ;)
> Anyone have any info
: > There are, as I see it, 3 general file-storage locations other than the
: > standard / and /usr systems.
: >
: > - files local to this machine (not network mounted)
: > - arch-dep files on this network
: > - arch-indep files on this network
: >
: > The FSSTND only had /usr/local and /usr/s
> > I lookd at how smail currently does it: it uses the crontab command to add a
> > crontab for the mail user. However, it doesn't check to see if the mail user
> > already has a crontab. Seems very broken to me.
>
> Try looking at how exim does it---it adds a crontab for the mail user, but
> doe
> > > > I think we can safely draw the line somewhere before sex with animals
> > > > and
> > > > incest.
> > >
> > > I am happy with this as long as you get rid of kjv-bible.
> >
> >
> > Me too!
> >
>
> Speaking as a Chinese and a Catholic/Christian:
>
> Please keep the Bible!
>
> An
> Ricardas Cepas thinks that we should map <-- to ASCII BS and `Delete'
> to ASCII DEL. Is there anyone else who agrees with him ? If not then
> I think we can safely go with my proposal, as it has rough consensus.
>
> If there is then I need to argue with him and to convince people.
I _disagre
What do I have to do to get some discussion about this?
> Does the FHS address both local and mounted directories? To explain...
>
> There are, as I see it, 3 general file-storage locations other than the
> standard / and /usr systems.
>
> - files local to this machine (not network mounted)
>
> Some time ago I posted the message below to debian-devel. It received
> widespread support and no significant opposition. I think it
> should be made policy.
yes, Yes, YES!!!
I agree completely with the entire proposal.
Brian
Does the FHS address both local and mounted directories? To explain...
There are, as I see it, 3 general file-storage locations other than the
standard / and /usr systems.
- files local to this machine (not network mounted)
- arch-dep files on this network
- arch-indep files on this network
I missed the original bit of this thread, so I have to ask...
Does the FHS address both local and mounted directories? To explain...
There are, as I see it, 3 general file-storage locations other than the
standard / and /usr systems.
- files local to this machine (not network mounted)
- arch-
63 matches
Mail list logo
