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
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
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Are we sure that a flat directory structure is good enough? I
> have tons and tones of icons gathered over the years, and I have to
> use the following directory structures. I find dividing the top level
> into types - background, 16x16, 32x32
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 s
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
In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>> "Darren" == Darren Benham <[EMAIL PROTECTED]> writes:
Darren> I was talking with one such human in IRC today and he basicly
Darren> said he'd get chewed out since there is no policy to reject
Darren> packages because t
Santiago Vila <[EMAIL PROTECTED]> writes:
> On 16 Oct 1998, Adam P. Harris wrote:
> > I think, say, filiing important bugs on the relevant packages would
> > suffice to ensure that the issue is fixed prior to the release.
> > Clearly I'm not proposing to do
There are a lot of issues floating around here.
First, administrivia. Ian originally said:
| I hereby propose an amendment to the Debian Developers' Reference,
| s5.5 `Interim Releases'
If this topic under discussion is a proposed correction to the
devel-ref, we should refile the bug according
Santiago Vila <[EMAIL PROTECTED]> writes:
> On 10 Oct 1998, Adam P. Harris wrote:
> > 2. info browsers, manual pagers, terminfo libraries, etc., are
>
> Yes, but where is the info program that looks in both directories?
> Before saying "this must be done in this way&
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Should we consider also a minor amendment to the guidelines
> asking the proposer to post a reminder midway through the discussion
> period, and then again at the end of discussion (reminding the
> maintainers)? Sometimes discussion dies down
I formally second the proposals in the BTS as 26461, 25385, and 21185.
I urge the originally submitter to get all the seconds in a row and
move towards a vote as quickly as our Policy Policy allows. If we
can't get these "no-brainer" type proposals to move through the system
at all then we have t
Santiago Vila Doncel <[EMAIL PROTECTED]> writes:
> On 21 Sep 1998, Manoj Srivastava wrote:
>
> > - ship HTML versions in the binary package, in the directory
> > - /usr/doc/package or its subdirectories.
> > + ship HTML versions in a binary package, under the directory
> > + /usr/doc/ o
Santiago Vila <[EMAIL PROTECTED]> writes:
> On Tue, 6 Oct 1998, Ian Jackson wrote:
> > (See also my post to debian-devel about this. In particular, I'm
> > opposed to /var/state and think we should ignore the FHS on this
> > point.)
> >
> > One of the key changes that the FHS has compared to the
[BTW, should I CC both the BTS *and* debian-policy?]
Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:
> As specified in policy, packages with shared libs generally run "ldconfig"
> from "postinst configure".
Actually, you're wrong, that's from the Packaging Manual, not the
Policy Manual.
> Thu
Darren Benham <[EMAIL PROTECTED]> writes:
> And what documents did Policy FINIALLY settle on assuming???
Packaging Manual and the Policy Manual. I think they all ceeded me
the Developer's Reference. I hope my recent work on that has
vindicated the idea that I can turn that document around more q
Darren Benham <[EMAIL PROTECTED]> writes:
> I'm looking over the contacts web page and I notice that there is still a
> policy manager listed (and attributed to Ian). I was wondering if there is a
> better name to fillin (Manoj?) or if that position should be removed.
Just yesterday I emailed tr
Guy Maor <[EMAIL PROTECTED]> writes:
> Just put non-free and contrib as part of the section. bash is in the
> base section. xv is in the non-free/graphics section.
Hmm. From a taxonomic standpoint, I don't like this, because now when
I'm talking about sections, I could either mean "non-free" or
Branden Robinson <[EMAIL PROTECTED]> writes:
> I wasn't attempting to imply you were wrong, just pointing out the
> need for consistency.
I agree. I need to be consistent with whatever is in Policy; that's
the bible. I think I've proven my point that the devel-ref is
consistent with Policy.
I'
Branden, in your suggested patch, you say:
Let me clarify and justify how I am using the terminology. I'm going
into some depth here, and bringing it up on the Policy list, since
this is the second time I've been "corrected" about the use of terms.
distribution:
A set of packages which ma
Please, everyone. Let's keep in mind that Brian is only trying to
improve the quality of Debian. Lets not forget that there *are*
maintainer who do not check their own bugs!
OTOH, Dale's request not to get the mail (calling it "spam") is
legally and morraly within his rights.
What I think is t
Manoj Srivastava <[EMAIL PROTECTED]> writes:
Adam> Yes, I mostly agree.
> Does that mean you second the proposal? I suggest we implement
> this part of the proposal first, and leave the issue of the source
> of the documentation to another ptoposal, since that is turning out
> to be controv
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I also further stated:
> I was not really suggesting replacing the info documentation
> (or the man pages, for that matter), I meant in addition to. The
> policy *does* say that HTML is our preferred format, so it should
> als
Zed Pobre <[EMAIL PROTECTED]> writes:
> [1 ]
> On Tue, Sep 15, 1998 at 11:06:58AM +0200, Santiago Vila wrote:
> > On Mon, 14 Sep 1998, Zed Pobre wrote:
> >
> > > + this string is reserved for the GNU Hurd operating system.
> > GNU/Hurd
> >
> > [ I think everyo
Santiago Vila <[EMAIL PROTECTED]> writes:
> On 5 Sep 1998, Manoj Srivastava wrote:
> > Do you not find the version numbers suggestive?
> >
> > debian-policy_2.4.1.3.deb
> > developers-reference_2.4.1.3.deb
> > packaging-manual_2.4.1.1.deb
Suggestive but not compelling.
> >
[You (Manoj Srivastava)]
> I hope I am not
> incorrect in assuming that the debian-policy, packaging-manual, and
> the developers-reference packages constitute the core of the policy
> documents.
Actually I see the developers reference as just another documentation
file. I've never seen to it
Package: debian-policy
Severity: normal
Version: 2.4.1.3
Christian Schwarz <[EMAIL PROTECTED]> writes:
> [Please CC: any replies to me since I'm not subscribed to this list.]
>
> I'm still listed as current maintainer of the virtual package name list,
> as distributed on ftp.debian.org (doc/pack
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
>
> Ian> I disagree with Manoj wrt the level of formality required for
> Ian> maintaining the policy document.
>
> Then your is the first objection that I have seen regarding
> the proposal.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> We are nearing the end of the proposed discussion period. The
> proposal so far has met with almnost universal approval
Let me just say right from the start that I think that your current
guidelines for updating policy (they really are guidelin
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Guy" == Guy Maor <[EMAIL PROTECTED]> writes:
> Guy> Now I'm confused. I thought we were talking only about technical
> Guy> proposals? Either way the rules for who can propose, issue,
> Guy> etc. technical and non-technical proposals are alread
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Guy" == Guy Maor <[EMAIL PROTECTED]> writes:
> Guy> If standards can't be modified, how can they be improved? I think
> Guy> there is gain in allowing standards to be modified. Modified
> Guy> standards must be distributed with a prominent noti
Daniel, for starters, this should probably be raised as a bug against
debian-policy, just to make sure taht we don't forget about it. We
are underway in debian-policy on finding a new way to maintain policy.
Right now, there basically *is* no policy editor. Submitting a bug
will make sure that s
I personally don't think splitting the lists is necessary. It's so
trivial to pick out what you want using mail filters. This fact, plus
the clear and obvious awkardness of your proposal w.r.t.
x86-centricity and where "source" and "all" pacakges go, is why we've
never bothered to change things.
I find two problems with Manoj's proposal.
Unlike before, when the policy editor gathered in issues which, in his
view, were candidates for inclusion in policy, I propose that issues
are brought up in the policy group, and, if the initial discussion
warrants it, any developer,
[Recipients stripped to the policy group]
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Buddha" == Buddha Buck <[EMAIL PROTECTED]> writes:
> Buddha> How will consensus be determined? Will one opposing
> Buddha> developer be able to force a deadlock? If not, how many?
>
> Human jud
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Martin" == Martin Schulze <[EMAIL PROTECTED]> writes:
> Martin> b) A set of web pages covering recent topics has to be set
> Martin> up and maintained. This could be master/~srivasta/ since
> Martin> it's not "that" official but could a
or date anywhere
+ * debian/rules: use dpkg-gencontrol -isp
+ * bugs fixed in some unknown previous version (closes Bug#23177)
+
+ -- Adam P. Harris <[EMAIL PROTECTED]> Sun, 26 Jul 1998 18:06:08 -0400
+
+debian-policy (2.4.1.2) frozen unstable; urgency=low
+
+ * non-maintainer release
+
Dale Scheetz <[EMAIL PROTECTED]> writes:
> The problem isn't in the postinst (I know neither of them use set -e) but
> in the preinst script. If that script fails then ae is not installed.
>
> All editors now use update-alternatives to place themselves in the
> priority queue for "editor". If upda
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> With the introduction of modutils 2.1.85-12 I think it's time to discuss
> kernel modules in here.
[...]
> I propose a section for this is added to policy manual which states both
> points.
No, I think this is more suitable as a "subpolicy", i.e., sgm
Rob Browning <[EMAIL PROTECTED]> writes:
> Michael Bramer <[EMAIL PROTECTED]> writes:
> > If this true, then we must move a lot of files from /var/lists/*,
> > /var/named (and more?) to /etc//
> Yep. For example, as far as I can tell, most of /var/named should be
> in /etc/named. Symlinks from /
Yann, following your summary of alpha/beta versioning, it seems to me
that a best practiced has arised and reached some consensus. I wasn't
following too closely, but I thought I saw this happening. Did it?
If so, could you just take the best practice, and, if it's something
requiring dpkg chan
"Scott K. Ellis" <[EMAIL PROTECTED]> writes:
> On Sat, Jul 04, 1998 at 02:16:59PM -0400, Gregory S. Stark wrote:
> > "Scott K. Ellis" <[EMAIL PROTECTED]> writes:
> > > You have libpkg, it is included in the apt package. Run ldconfig.
> >
> > Uhm, shared libraries are supposed to be in separate p
Geeze, the crossposting is horrendous. I don't see this as a policy
issue, so followups to debian-devel or debian-user only please.
Dale Scheetz <[EMAIL PROTECTED]> writes:
> On 29 Jun 1998, Manoj Srivastava wrote:
> > Make bug reporting any more onerous than it is, and peole
> > merely sto
Rob Browning <[EMAIL PROTECTED]> writes:
> Philip Hands <[EMAIL PROTECTED]> writes:
> > I was just using that as an example of an existing package that had
> > multiple
> > minuses in the version.
> >
> > I didn't make it up, I got it out of hamm:
> >
> > hamm/hamm/binary-all/doc/libc6-pre
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Bill" == Bill Mitchell <[EMAIL PROTECTED]> writes:
> Bill> That's pretty messy, however. Perhaps, since other packages
> Bill> may presume the presence of the undocumented(7) man page
> Bill> without declaring a dependency on the manpages packag
In message <[EMAIL PROTECTED]> you wrot
>> You may mark this bug as forwarded and make a link of tzconfig.8 to
>> undocumented(7), following policy.
>>
>This policy has created one of the most cluttered, ugly, and useless,
>method of dealing with the lack of man pages.
>
>It doesn't create any use
This (trimmed) output from pkg-deps has me a little concerned about
the policy compliance from Section 4.5 of policy:
| All Debian MUAs and MTAs have to use the maillock and mailunlock
| functions provided by the liblockfile packages to lock and unlock mail
| boxes. These functions implement a NF
Guys, maybe this has been discussed before, although it looks like the
bug is still open.
Federico Di Gregorio <[EMAIL PROTECTED]> writes:
> I am writing a little font manager for debian (dtm, you can find
> it in slink) and some time ago I proposed to put all the fonts
> (the one independ
I know this thread is old but I felt obliged to comment. I have
sugically removed most of the messages. The snippets that remain
show, I think, how Manoj and Dale are speaking at cross-purposes, that
is, both seem to have problems understanding the other's position
fully, so argument is (was) go
"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Sat, May 02, 1998 at 04:15:54AM -0400, Adam P. Harris wrote:
> But hang on; Branden's whole point was that runlevels could solve
> the xdm & xfs mess in the /etc/X11/config file; your runlevel
> pro
Branden Robinson <[EMAIL PROTECTED]> writes:
> In bashing my head against X for a while I've come to the realization that
> perhaps it's time we come up with some official policy regarding runlevels.
Yes... Solaris has it, so should we. ;)
> As it stands (as I understand it), runlevels 2 through
[EMAIL PROTECTED] writes:
> On Sat, Apr 25, 1998 at 11:31:20AM -0400, Bob Hilliard wrote:
> > This sounds like a mistake to me. Presently the debian
> > maintainers are responsible for providing manpages for their
> > packages if the upstream source doesn't contain them. Providing
> > some i
Christian Schwarz <[EMAIL PROTECTED]> writes:
> On 17 Apr 1998, Adam P. Harris wrote:
> No, that's not the point. (Please correct me if I'm wrong again.) If a
> package does not provide a .dhelp file itself, doc-base will create this
> file automatically. Only doc-bas
Christian Schwarz <[EMAIL PROTECTED]> writes:
> On 16 Apr 1998, Manoj Srivastava wrote:
> > >>"Bob" == Bob Hilliard <[EMAIL PROTECTED]> writes:
> >
> > Bob> A standard would become meaningless if anyone were allowed to
> > Bob> modify and circulate it freely. These copyrights are clearly
> > Bob>
Martin Mitchell <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Adam P. Harris) writes:
> > File renaming is up to the package maintainer. Give us our freedom to
> > make out operating environment better than anyone's!
>
> I'm not trying to remove
Martin Mitchell <[EMAIL PROTECTED]> writes:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
> > Martin> I don't call changing filenames in original documentation
> > Martin> easily maintainable.
> > I find this hardly onerous at all. I have a rules file. It was
> > set up when I first set up t
Christian Schwarz <[EMAIL PROTECTED]> writes:
> On Sat, 18 Apr 1998, Anthony Towns wrote:
> > On Fri, Apr 17, 1998 at 12:34:18AM +0200, Christian Schwarz wrote:
> > > I agree that the extra files should *not* be purged
> > > automatically. However, dpkg should not forget about them.
> > I disagre
[EMAIL PROTECTED] writes:
> On Tue, Apr 07, 1998 at 10:39:42PM +0100, James Troup wrote:
> > and ask the maintainer to close them, but the maintainer should be
> > the one closing bugs, not some random individual on a clean up
> > crusade.
>
> I think this is an issue where it is difficult to lay
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> I think we should have a more formal definition of Debian's files, and
> which is the right way to parse them...
Or, for slink, we just strip down dpkg (take out package dependancy
calculation), put /var/lib/dpkg/info/* and /var/lib/dpkg/status int
[You ("David Engel")]
>On Sat, Mar 28, 1998 at 12:57:35PM +1100, Herbert Xu wrote:
>> they're not. This seems to indicate that we must run ldconfig in postinst e
>ven
>> if there're symlinks in the package.
>This is correct -- you must run ldconfig. If the new libraries are
>installed into /lib
[You (Sven Rudolph)]
><[EMAIL PROTECTED]> writes:
>
>> Package: lprng
>> Version: 3.4.2-1
>>
>> to make sure /sbin and /usr/sbin is in the PATH
>> (which might not be with some administrate accounts,
>> that su to root to start the spooler).
>
>Some /etc/init.d/ scripts (re)set PATH; others don'
[You (Manoj Srivastava)]
> Firstly, I think we should minimize the number of conffiles on
> the system. A one line addition to the script shall meke this
> unnecessary.
Ok, well, I see your point. I still don't agree and I think a uniform
administrative GUI would be a better solution. I
[You (Manoj Srivastava)]
>>>"aph" == aph <[EMAIL PROTECTED]> writes:
>
>aph> To support users on PPP links, I suggest you add a conffile shell
>aph> script in /etc/ppp/ip-up.d/distributed-net. A possible version
>aph> of that file:
>
>>> !/bin/sh
>
>aph> [ -x /usr/bin/distributed-net ] && distri
"Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>> "aph" == aph <[EMAIL PROTECTED]> writes:
aph> Package: sendmail Version: N/A
aph> You ought to have a little shell script in
aph> /etc/ppp/ip-up.d/sendmail, make that a conffile. This script
aph> could flush the queue when the link come
"Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
> So, what does the check mean? 66 packages install files into
> /usr/share. It seems OK to put files in there, as long as no program
> ever references thos files directly. Is that right?
Yes, it is literally correct according to FSST
[You (Rob Browning)]
>Yann Dirson <[EMAIL PROTECTED]> writes:
>> The problem I have with epochs is that it will have to bump each time
>> a packages enters a "pre" period. I fell that's not very nice.
>
>What difference does it make?
In truth, non.
OTOH, I too would be very hesitant to instance
[You (Michael Bramer)]
>I think we should make a new policy:
>
>All pixmaps and bitmaps are locate under
>/usr/X11R6/include/X11/[pixmaps|bitmaps].
I agree that this should be where pixmaps and bitmaps go; however I
disagree that this should be policy. Point (a): it's covered by FSSTD,
point
[You (James Troup)]
>Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> What *did* you mean here?
>
>s/a trite argument/incorrect/.
I'd have to agree with James that the bugs against 'dpkg' are not so much
an argument against 'dpkg' as a testimonial to the curse of dpkg. A very
strange curse. A
[You (Yann Dirson)]
>However, I would strongly advise not to use a standalone file like old
>.du files and .md5sums: the largest part of these files is occupied by
>the filenames, which are already profided by .list files.
>
>I'd suggest that we evolve towards a new generic control-file (say
>pack
[You (Manoj Srivastava)]
> Did we ever reach a consensus about the relative vs absolute
> links in packages? Was it decided that links between top level
> directories should be absolute, whereas links within on should be
> relative?
I agree that this is reasonable but I'd like to see the o
[You (=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?=)]
>[Rob
Browning]
>> What I would like to see considered for policy (because I'm lazy), is
>> that for packages that only have info pages, in lieu of writing
>> manpages (which may or may not actually happen), we have a manpage
>> info-documented.1.gz t
[You (Manoj Srivastava)]
>Zed> After having lurked in debian-devel for a while, I suspect that
>Zed> Manoj will object that developers for Debian need to be sufficiently
>Zed> proficient in writing shell scripts and whatever else that they can
>Zed> deal with this on their own.
>Zed> I think that
[You (Joey Hess)]
>Manoj Srivastava wrote:
>> So what? what are postinst files for? Which games need a
>> binary high scores file?
>
>Oh, for example, xboing, nighthawk, thrust, xgalaga, xhextris, xtrojka,
>abuse, canfield, robots, sail, snake, tetris-bsd, phantasia, rogue,
>maelstrom, xkobo
[You (Hartmut Koptein)]
>Hello,
>
>> Since, by current policy, all games (even X11 ones) go into /usr/games,
>> manual pages should also go into /usr/man.
>
>must this discuss on debian-devel or is this the last word? If so, we can
>go to change it in our gg (great-games) :-)
I think for now we o
I would like to make it policy that cron jobs do not emit any message
during normal processing. Here's a possible wording:
Any cron job which is installed should not emit any messages to
STDOUT or STDERR during normal processing. Messages should
only be emitted if an unexpected c
Well we seem to have consensus that LOG_LOCAL* should be indeed local
as it says. I believe we should add it as policy.
Maybe I'm just becoming a bureaucratic policy fanatic. OTOH, maybe
it will be a good thing to make this explicit policy. Then maybe
someone will get up the gumption to add so
"fpolacco" == fpolacco <[EMAIL PROTECTED]> writes:
>> On Sun, 15 Feb 1998 [EMAIL PROTECTED] wrote:
>> > Therefore I think that it is better to leave them mode 444 so a user
>> > (educated by Slackware) will find little more difficult to modify them
>> > (mode 444 should make him think that that f
[You (Manoj Srivastava)]
>Hi,
>
> Until we have a tool, I do not think we can determine the
> input format for such a tool. Packaging files that could possibly be
> the input for an as yet unwritten tool (we are not clairvoyant, are
> we now?) is slightly silly.
I have to heartily agree wit
[You (Karl M. Hegbloom)]
> Some more facilities should be hacked into syslogd, I think.
>
> Hmmm... fax, ppp, www, isdn(?), uhhmmm... what else?
I would have all dialout stuff (chat, ppp, isdn-ppp) go to a 'serial'
facility, or perhaps a better name (dialout is not good, since it could
be dial
This is concerning Bug#17908, which is a bug I filed against
debiandoc-sgml for no man page for
/usr/lib/debiandoc-sgml/bin/saspconvert. I felt that I should retract
the bug since the program is under /usr/lib.
[You ([EMAIL PROTECTED])]
>I was just checking the Debian web pages and saw your b
[You (Manoj Srivastava)]
> The problem with this is that specifying a syslog policy is so
> hard to do (it is a very personal issue).
Sure, but I think we could keep our thoughts at the level of "what would
you think is reasonable out of the box". There's a lot of generality;
the baseli
[Redirected to ]
[You (Manoj Srivastava)]
> Is there any policy/convention about using facilities local0
> though local 7? I notice that ppp has take onver local2 and local5
> now belogs to hylafax (on my machine).
> I ask this since I want to add a chanel to named for logging
> all
"David" == David Frey <[EMAIL PROTECTED]> writes:
> I today just found out, that my magicfilter violates the newest
> policy by rewritting /etc/printcap, which is lpr|lprng's confile.
> What would be the correct solution for this problem? Shall I require
> that the lpr|lprng maintainer writes a mo
"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Thu, Jan 15, 1998 at 01:22:01AM +0500, Adam P. Harris wrote:
>> Tut tut! What you really mean must be: does nothing but exits with
>> a non-zero status. Or else we need to reword PW#5-5.
> Is a non-z
"Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:
> On Wed, 14 Jan 1998, Steve Greenland wrote:
>> On another note, what about things like cron, which don't *need*
>> reload -- it tracks its conffiles, and reads them whenever they
>> change. Should it just implement reload and force-rel
[Sorry to be offtopic a bit]
"Remco" == Remco Blaakmeer <[EMAIL PROTECTED]> writes:
> 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 "mos
"Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:
> [This mail is part of Debian Policy Weekly issue #5]
>
> Topic 10: System-wide environment variables used for program
> configuration
I agree with this Topic, but I just want to play devil's advocate a
bit.
> No program may depe
"n" == n writes:
>> It is de facto, if not policy, that icons are
>> /usr/X11R6/include/X11/pixmaps.
> Just for clarification. Applications must make references to this
> directory instead of /usr/share/..., is that right? And the files
> should be installed in /usr/X11R6/include/X11/pixmaps? E
[You (Kai Henningsen)]
>[EMAIL PROTECTED] (Rob Browning) wrote on 23.12.97 in <[EMAIL PROTECTED]
>re.csres.utexas.edu>:
>> "Adam P. Harris" <[EMAIL PROTECTED]> writes:
>> > I think you're (a bit) unduly alarmed. From my interpretation, it'
Redirecting to debian-policy. Followups to debian-policy only please.
[You (=?ISO-8859-1?Q?Marcelo_E=2E_Magall=F3n?=)]
>On Sun, 21 Dec 1997, Adam P. Harris wrote:
>
>> [You (Karl M. Hegbloom)]
>> > I've created a directory "/usr/X11R6/icons" for my own use.
[CC'ing debian-policy]
"Jim" == Jim Pick <[EMAIL PROTECTED]> writes:
>[I wrote]
>> Yes, it is discussed in the Debian Packaging Manual, section 12.
>> See: /usr/doc/dpkg/packaging.html/ch-sharedlibs.html
>> You should just go ahead and file bugs against packages which don't
>> include the .so li
I have a question:
Who has authority to mess around with the bug report? From
http://www.debian.org/Bugs/Developer.html>, it looks like any
developer who gets a mind to is "authorized". Is this something that's
possible but not recommended?
Possible answers:
* anyone!
* any debian devel
[You (Sten Anderson)]
>Rob Browning <[EMAIL PROTECTED]> writes:
>> Feel free to let me know if you have suggestions about how this
>> package should be handled. I'm planning to cooperate with the xemacs
>> and emacs (19) package maintainers to make sure we support the
>> simultaneous installation
93 matches
Mail list logo
