Michael Biebl wrote:
On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote:
The FHS requirement that architecture-independent application-specific
static files be located in /usr/share is relaxed to a suggestion.
In particular, a subdirectory of /usr/lib may be used
Johnathan raises important concerns in
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=628515
These have never been addressed by any proponents of verbose build logs
AFAIK.
I raise similar concerns in #680686. There is also discussion there of
making dpkg-buildpackage produce a smart
Bill Allombert wrote:
The issue is that it is dangerous to upload packages built with a different
DEB_BUILD_OPTIONS than the one on the buildd.
Much less dangerous than it is to upload packages built with a different
dpkg-buildpackage -j
--
see shy jo
signature.asc
Description: Digital
Charles Plessy wrote:
Le Sat, Aug 31, 2013 at 06:17:29PM +0900, Charles Plessy a écrit :
In any case, we need one more Developer to support this patch before
applying to
the Policy. Once we have this extra assessment for consensus, I will apply
it
unless there are clear
Charles Plessy wrote:
About the specification of the commit hash: why is it not needed for a package
uploaded to a given suite, that the commit is reachable in refs/dgit/suite ?
AIUI this is because packages move between suites in the archive without
that move necessarily being immediately
Charles Plessy wrote:
As proposed in 2010 (http://bugs.debian.org/190753#98), I would like to ask
the
Technical Comittee to reconsider our Policy, and restrict it to cases where
the
name of a program is an interface (http://bugs.debian.org/190753#128).
Actually, my message
I'd suggest that, in cases where the name of a program is an interface[1],
and includes the implementation language, it would be reasonable, and
in the spirit of my original policy proposal, to ship a symlink that
does not include the implementation language in its name, and retain the
interface
David Prévot wrote:
Since there seems to have issues with html2txt, and the policy advises
the use of lynx [0]
No, policy gives an *example*, which happens to use lynx.
what about reverting your almost ten years old
change (#93747) and get back to depend on lynx ?
If anything, I would be
FWIW, the installation-locale udeb provides a C.UTF-8 locale,
which d-i runs under. Takes about 168k.
--
see shy jo
signature.asc
Description: Digital signature
Julian Andres Klode wrote:
Quoting 3.9.1:
Packages which use the Debian Configuration management specification must
allow for trans-
lation of their messages by using a gettext-based system such as the one
provided by the
po-debconf package.
But internal debconf questions should not be
Josselin Mouette wrote:
Therefore, I still feel that, despite it being a big mess, the current
situation is the best:
* the default menu contains only what is needed, and we are still
hunting down entries that are useless to make them not show up
by default;
*
Mikhail Gusarov wrote:
fd.o menus are designed to allow distro-specific policy. It's the matter
of Debian KDE/Gnome packaging/menu policy to get the proper subset of
the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE
menu and Qt/KDE - in Gnome one).
That might work for
Joerg Jaspert wrote:
The code in dak, in the current form, is there since 2002-02-13, when
jennifer (today process_unchecked) got added to the repository. Most
probably something similar existed in the code before this.
Its also nearly unchanged since then, with changes being cosmetical.
Nice
Package: debian-policy
Version: 3.7.3.0
Severity: normal
You must specify the gcc option `-D_REENTRANT' when building a library
(either static or shared) to make the library compatible with
LinuxThreads.
AFAIK we don't use linuxthreads anymore, and I checked a few libraries and
Russ Allbery wrote:
I understand that you and a few other DDs feel that way, but you appear to
be outnumbered at the moment.
By whom? IIRC I've heard both release team and security team members
state they prefer dealing with packages that don't use those things, and
a majority of packages don't
Joey Hess wrote:
3714 source packages have Vcs-* fields, that's more already than those
2133
Bad grep that double counted packages with Vcs-Browser. I think the 4
month end of my estimate still stands.
--
see shy jo
signature.asc
Description: Digital signature
Russ Allbery wrote:
Bernd Zeimetz [EMAIL PROTECTED] writes:
Which will only give useful results if we have a central repository for
all packages. If $RANDOM maintainer uses his own machine to host a
repository and goes MIA, you'll be left with one large and messy patch
as you don't have
Russ Allbery wrote:
Well, basically every discussion about this that I've seen on -devel,
discussions on -mentors, the teams that I'm familiar with (pkg-perl is
standardizing on quilt
I'm a member of pkg-perl, and 52 packages out of ~500 use quilt. We also
have 20 packages using dpatch, and 45
Russ Allbery wrote:
Having the repository on alioth doesn't necessarily help if you're talking
about something like Subversion (and particularly CVS) depending on the
use case. I don't think we really get back the functionality of quilt
until we're shipping the repository with the source
lpr's standard priority nonwithstanding, CUPS has been the default print
system in Debian -- if you select the desktop or print server tasks --
for at least the last two releases. This is why popcon shows 5000 lpr
installations to 45000 cupsys installations.
Yes, it would make more sense for
Kurt Roeckx wrote:
Atleast some packages now don't run the testsuite when
DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE.
Are there any other reasons why testsuites shouldn't be run?
Speed, and wanting to build a package even if its test suite is broken,
I guess.
Neil Williams wrote:
There needs
Manoj Srivastava wrote:
On Sun, 22 Apr 2007 19:29:55 -0400, Joey Hess [EMAIL PROTECTED] said:
So while I'd love to have a way to have -dbg packages available for
every binary, I actually am happy with this proposal to do it for only
every library (plus whatever other binaries really need
Otavio Salvador wrote:
When I deal with my packages I put that kinda of bug in
'grave'. Doesn't mind to me if the affected group is 1 or 1k people.
I'm talking about /bin/sh but it's far from that simple
problem. That's the way people are handling bugs. In my POV the text
that define the
sean finney wrote:
this is a surprising change. guess that's what i get for not being
subscribed to -policy :)
Not really, it was last discussed on -policy in 2003, so being
subscribed wouldn't have helped, I'm as suprised as you are.
but i'm still grappling to understand the rationale
sean finney wrote:
- that cgi-bin is defined to be a location outside of debian packages'
reach entirely (/srv/www/cgi-bin or /var/www/cgi-bin, or whatever).
- httpds which support scriptaliasing ship this as the default location
- httpds which can not scriptalias it somewhere else (those
Package: debian-policy
Version: 3.6.2.2
Severity: normal
Section 11.8.5. is no longer current regarding the font paths used by
the new modular version of X. Packages providing fonts need to drop them
into /usr/share/fonts/X11/ now, I guess. It would probably help if the X
maintainers sent in a
Seconded once more.
--
see shy jo
signature.asc
Description: Digital signature
Lars Wirzenius wrote:
Current policy states in section 9.3.3.2 (Running initscripts) the
following: The use of invoke-rc.d to invoke the /etc/init.d/*
initscripts is strongly recommended[51], instead of calling them
directly.
Footnote 51 further says: In the future, the use of invoke-rc.d
Package: debian-policy
Version: 3.6.2.1
Severity: normal
3.9 does not describe the current tasksel/tasks situation very well.
You should not tag any packages as belonging to a task before this has
been discussed on the _debian-devel_ mailing list and a consensus
about doing that
Ola Lundqvist wrote:
Hello
On Sat, Jul 30, 2005 at 12:00:32PM +0200, Marc 'HE' Brockschmidt wrote:
Ola Lundqvist [EMAIL PROTECTED] writes:
I do not really see a problem here. All gnustep packages store
files in a (at least sort of) FHS compliant directory:
/usr/lib/GNUstep
Are
Michael Shields wrote:
What ever happened with this proposal you made in April 2003? Is it
waiting on something?
Good question. I don't know why this accepted policy amendment with no
dissenters and three seconds hasn't been included in any of the three
releases of the policy manual made
Debian policy is still stuck requiring FHS 2.1, although a copy of FHS
2.3 is included in the debian-policy package. As noted in bugs 212434
and 230217, the changes needed to upgrade to 2.3 are not too large, and
consist of:
2.1 to 2.2:
- new location for adjtime file (#156489)
- #212434 and
Manoj Srivastava wrote:
The reason this has not changed is because back in october, we
had a large, unresolved discussion both on the policy and the devel
mailing lists that went over the changes, point by point, and people
pointed out that there were obstacles to just recommending
Mark Brown wrote:
On Tue, Dec 30, 2003 at 10:18:18AM -0200, Henrique de Moraes Holschuh wrote:
On Tue, 30 Dec 2003, Dan Jacobson wrote:
not restart the services on package upgrades. Broken ones still calling
/etc/init.d/whatever directly will, but that's a bug: report it whenever you
Fabio Massimo Di Nitto wrote:
I am cross posting this answer but I think we should keep the
discussion on one mailinglist only. I leave up to you which one you think
is more appropriate.
I'd prefer debian-policy.
- Some web servers (eg apache2) can cooexist with other web servers
Daniel Stone wrote:
I'm not sure I love the /debian-www/ bit; it's a bit aesthetically
displeasing, but to each their own. Good idea otherwise, however.
I agree, it is not the prettiest name. I considered just /debian/, but
it seemed more likely that would conflict with something on someone's
Maybe it's time to think about amending section 11.5. of policy (Web
servers and applications) to address some of the problems with it. Here
are the problems I know of:
- Some admins want to tightly control which cgi scripts are available,
beyond merely picking packages to install. For
Package: debian-policy
Version: 3.6.1.0
Severity: normal
Section 3.6.1.0 of policy recommends registering HTML documents with the
menu package. AFAIK this practice has been supersceded by doc-base.
Although oddly, I see no mentions of doc-base in policy.
-- System Information:
Debian Release:
Josip Rodin wrote:
Well, regardless of whether we pick versions or listing available targets,
why not do it with a new control file field in the source section?
That seems logical, and avoids creating a new file.
It's tangentially relevant that the .dsc and .changes files include a Format
Colin Watson wrote:
Using separate environment
variable names would fix that problem, not that I particularly relish
the idea of trying to get it changed everywhere.
Me either.
If we didn't want to change the existing flags, we could still reserve
DEB_BUILD_OPTIONS_* for extensions.
I'd
Robert Jordens wrote:
+ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS)))
+PARALLEL_JOBS := $(shell echo $(DEB_BUILD_OPTIONS) | \
+sed -e 's/.*parallel=\([0-9]\+\).*/\1/')
+ifeq ($(DEB_BUILD_OPTIONS),$(PARALLEL_JOBS))
+PARALLEL_JOBS := $(shell if [ -f /proc/cpuinfo
Andrew Suffield wrote:
Isn't useless makework for the maintainer the point of
lintian/linda? :P
:-)
The value is rather limited though... two cases I can think of, are
trying to build the arch-dep components (which should do nothing,
successfully) and adding an arch-dep component to the
A strict reading of policy now indicates that Build-Depends-Indep need
not ever be satisfied when the clean target is called. Apparently this
change was made to document autobuilder behavior when building packages
that mix arch all and arch any components, but as I read it, the effect
is broader.
Joey Hess wrote:
If build-depends-indep need not be satified any time the clean target is
run, then I can imagine that some tool might be written to rely on that,
and only install the build-depends before building a package that is
only arch: all.
Rather, that some tool remove the build
Wouter Verhelst wrote:
This has led to the confusion that people thought build-depends were
intended for arch-dependent packages *only*. That isn't true.
Build-depends should contain build-dependencies that are common to
arch-independent and arch-dependent packages, as well as
Andrew Suffield wrote:
Not quite; it should be modified to explicitly exclude
debhelper. There are very few packages which are actually needed at
clean time - the warning is correct for most things.
That does not agree with what Wouter said.
Wouter Verhelst wrote:
When build-depends were
Manoj Srivastava wrote:
* #172436: debian-policy: [PROPOSAL] web browser url viewing
Package: debian-policy; Reported by: Joey Hess [EMAIL PROTECTED];
days old.236
This proposal was initially seconded, but then discussion
turned up some
Jakob Bohm wrote:
Note that only a few packages will need these dependencies,
unlike libc6. Specifically, these packages will be needed by a
subset of the packages that currently Depends: adduser .
You have to depend on adduser?
Oops.
Adjust your numers accordingly. :-)
--
see shy jo
Matt Zimmerman wrote:
It might be a good idea to specify how quoting should be handled, both for
shell metacharacters and format specifiers.
Well, it's been discussed several times before, but what the hey, I
guess I can discuss it one more time.
My browser proposal assumes that
Colin Watson wrote:
On Sun, Aug 03, 2003 at 07:48:43PM -0400, Matt Zimmerman wrote:
It might be a good idea to specify how quoting should be handled, both for
shell metacharacters and format specifiers.
Odd, I thought I'd mentioned
http://www.dwheeler.com/browse/secure_browser.html in
Andrew Suffield wrote:
Hold that thought. We hashed out a few ideas on IRC; more in a few
days. Meanwhile, let's assume it will be solved... anything else?
I missed that discussion, but the obvious approach in fakeroot is user
autovivification (to bottow a term from perl) on chown.
--
see shy
Manoj Srivastava wrote:
How does one discover these templates then? Is this a
hit-or-miss effort based on the packages I may have installed on my
machine? Seems to me that makes it very likely that the user shall be
bombarded with identical questions on install then; I think this
Mark Baker wrote:
I believe exim4 should be the default mailer by the time sarge is
released, at least if its maintainers believe it is stable enough (I'm
now using it myself on my server, and I believe that it is).
Has there been any progress on getting exim4 into base yet? It's best to
do
Josip Rodin wrote:
On Sat, Jul 12, 2003 at 12:25:50AM -0400, Joey Hess wrote:
I believe exim4 should be the default mailer by the time sarge is
released, at least if its maintainers believe it is stable enough (I'm
now using it myself on my server, and I believe that it is).
Has
Andreas Metzler wrote:
I have not doublechecked packages.d.o. but the package's control file
lists exim4, exim4-config, exim4-base and exim4-daemon-light as
Priority: important and I cannot remember getting a mail about
override disparities.
It does have that priority, but debootstrap still
Colin Watson wrote:
I'm slightly concerned by how we're going to map onto other systems'
uses of 32-bit uids here, since there will already be some. 0-99 and
6-64999 were reasonably obvious back in the day, but I don't have a
feel for how big systems are allocating uids now. I would be
Chris Waters wrote:
$PAGER is a different case. I might consider a proposal that $PAGER
should only be used for terminal apps. That's historically how it's
used for the most part, anyway. In fact, if we look around, I bet
we'll find that most X apps ignore $PAGER, whether they're part of an
Ok, discussion turned up two problems, fixable by changing two words:
Web browsers
Some programs have the ability to launch a web browser to display an URL.
Since there are lots of different web browsers available in the Debian
distribution, the system administrator
I just noticed, somewhat to my suprise, that this proposal is not in
policy despite being fully implemented in debian now. Maybe it's because
of Ian's reply.
Ian writes:
This is a bad idea because it will be very annoying if the URL is
unfetchable - all the browsers will be launched in
(Please restrict followups to the bug report, it's a PITA to have to go
back and search debian-policy for discussion relating to a proposal.)
Colin Walters wrote:
If the BROWSER environment variable is not set, the program should use
| /usr/bin/x-www-browser if DISPLAY is set,
This, I have
This proposal is probably great for unintegrated environments, but some
sort of exception should be made for integrated ones.
The funny thing is that this proposal is just a reworking of section
12.4 of policy which deals with editors and pagers. If we have
integrated environments in debian
Steve Kowalik wrote:
At 8:49 pm, Monday, June 2 2003, Josip Rodin mumbled:
I don't know exactly why it's done that way (it was introduced long before
I ever became a Debian developer), but it's the scheme we use and we're
keeping it, for consistency and backwards compatibility (we have
Chris Waters wrote:
The whole point of keeping menu policy separate was so that it would
be easy to modify without all the overhead of making formal policy
changes. I'm a little perturbed that we seem to have lost that.
Well, it's not clear from reading the various files in
Bill Allombert wrote:
There is a Games/Sports section defined as games derived from real
world sports. I think csmash and gtkpool fit this criterium.
I suppose. Then do we have enough simulations to warrant an
Games/Simulation?
The simulatian-ish things I find with a quick search are:
-
Jack Howarth wrote:
dh_shlibdeps should be performing a 'ldd -d -r'
on each library in a package and issuing a warning if undefined
symbols are detected. The warning issued by dh_shlibdeps should be
simply that Additional linkage *may* be required for this shared
library.
You must mean
Lars Wirzenius wrote:
Indeed. With people using tiny laptops with 640x480 pixel screens to
people using high-end workstations with two (or three?) multi-megapixel
screens, there isn't any one size that will fit all.
What Gnome, OS X, and KDE do is to provide icons in a large size that is
David B Harris wrote:
(Note that I'm subscribed to the list, no need to mail me personally.)
On Tue, 13 May 2003 15:58:49 -0500
John Goerzen [EMAIL PROTECTED] wrote:
On Tue, May 13, 2003 at 04:30:10PM -0400, David B Harris wrote:
Instead of adjusting this to 48x48 to match current common
Bill Allombert wrote:
Here an extract from the menu manual:
Debian package maintainers should ensure that any icons they include
for use in the debian menus conform to the following points:
1. The icons should be in xpm format.
2. The icons may not be larger than
Richard Braakman wrote:
On Tue, Apr 22, 2003 at 10:03:44PM +0200, Bill Allombert wrote:
I would personnally be fine with only:
When scripts are installed into into a directory in the system PATH,
the script name should not include an extension such as .sh or .pl
that
Bill Allombert wrote:
I would second it, but I do not like the wording:
When scripts are installed into /usr/bin or other directories in
the PATH
why not:
into a directory in the system PATH,
I don't see much benefit either way. Reads the same to me.
There may be rare
Package: debian-policy
Version: 3.5.9.0
Severity: wishlist
I suggest we add the following to policy section 11.4.
(Wording by Bill Allombert.)
When scripts are installed into into a directory in the system PATH,
the script name should not include an extension such as .sh or .pl
There seem to be more and more packages that are dumping programs into
/usr/bin or elsewhere and givning them names with end in .pl, .sh, .py,
.tcl. etc. I hadn't realized exactly how many there were until I looked
through a ls /usr/bin/*.* on my system, and found almost a dozen, like
these:
I thought that policy used to have something to say about over-noisy
maintainer scripts along the lines of leave the progress reporting to
dpkg, but I cannot find it. Was this lost in a reorg?
--
see shy jo
pgp6rXYqKlrEq.pgp
Description: PGP signature
Dan Jacobson wrote:
Anyway, here's a typical case.
$ apt-cache show flightgear
...
Description: Flight Gear Flight Simulator
Flight Gear is a free and highly sophisticated flight simulator.
.
This package contains the runtime binaries.
This description sucks. Adding an url to it will
Colin Watson wrote:
I object. It's a waste of considerable effort to go around adding This
package has no upstream URL to several thousand packages. I think we've
already informally agreed that having upstream URLs in package
descriptions [1] where packages.debian.org can see them is a good
Jerome Marant wrote:
I've sent a patch for Debhelper (See #85963) but it won't be applied
as long as Policy don't say so.
When did I say that? I am still unhappy with the implementation in
debhelper, is all. (Modify policy to get rid of the /usr/X11R6/man/ tree,
and I would be able to implement
Josip Rodin wrote:
Think harder. :) A user runs man x-window-manager once, sees something,
later the alternative gets changes to another WM for whatever reason, they
run man x-window-manager again, see another thing, confusion ensues.
editor(1) and pager(1) and www-browser(1) are already
Jérôme Marant wrote:
Joey Hess [EMAIL PROTECTED] writes:
Jerome Marant wrote:
I've sent a patch for Debhelper (See #85963) but it won't be applied
as long as Policy don't say so.
When did I say that? I am still unhappy with the implementation in
debhelper, is all. (Modify policy
Jérôme Marant wrote:
Joey Hess [EMAIL PROTECTED] writes:
Josip Rodin wrote:
Think harder. :) A user runs man x-window-manager once, sees something,
later the alternative gets changes to another WM for whatever reason, they
run man x-window-manager again, see another thing, confusion
James Blanford wrote:
I am concerned with a new trend that uses debconf to configure personal
information into system files. I'll start with an exaggerated example.
I have a Window Maker dockapp, wmbday, that counts down the seconds to
my birthday and then displays the message, Happy
Package: debian-policy
Version: 3.5.8.0
Severity: normal
D.2.9. `Section' and `Priority':
See the Debian policy manual for the priorities in use and the criteria
for selecting the priority for a Debian package
Heh.
-- System Information:
Debian Release: testing/unstable
Architecture:
Josip Rodin wrote:
And you are totally ignoring what I wrote in my initial mail!
I'm sure your mail was the most important post on the thread and stuff,
but -
a) I am catching up from a 40 thousand message, 1 month backlog, and
frankly whatever you said didn't really stick in my mind.
b) I
Josip Rodin wrote:
On Sat, Feb 08, 2003 at 07:15:52PM -0500, Joey Hess wrote:
Adding 1100 additional packages to debian
This tendency to fuck up a discussion, despite my best efforts to talk
about a compromise right from the start, is very frustrating.
% grep-available -F Package -r 'lib
Jamin W. Collins wrote:
Would moving the static libraries to separate packages increase the
number of package in Debian, certainly. Would this be bloat, I don't
see it as such. To consider this as bloat is to consider the choice of
editors available in Debian (~100+ according to a quick
Joey Hess wrote:
Jamin W. Collins wrote:
Would moving the static libraries to separate packages increase the
number of package in Debian, certainly. Would this be bloat, I don't
see it as such. To consider this as bloat is to consider the choice of
editors available in Debian (~100
Anand Kumria wrote:
What is the opinion of this group?
[EMAIL PROTECTED]:~dpkg -p debian-policy
Package: debian-policy
Priority: optional
Section: doc
Installed-Size: 1448
Maintainer: Debian Policy List debian-policy@lists.debian.org
--
see shy jo
pgpYYjt8oNGrQ.pgp
Description: PGP
The policy text needs to have sensible-www-browser replaced with
sensible-browser, which is the real name of the program in
debianutils.
--
see shy jo
pgpjGcd8WlILV.pgp
Description: PGP signature
James R. Van Zandt wrote:
I think the link in the copyright file to the upstream sources should
be in a standardized, parsable format. Likewise the author name.
That way lintian could check for them. The last time I checked, 5 or
10 percent of our packages lacked any link to the upstream
Package: debian-policy
Version: 3.5.8.0
Severity: normal
As discussed earlier on this list, and now implemented by lots of stuff
in Debian[2] and with only a few to go[3], I'm proposing that the
following be added to policy around section 12.4:
Web browsers
Some programs have
Adam DiCarlo wrote:
Huh. I'll have to play around with this. I would indeed rather use a
field, even a custom field, if possible, since this is really data.
I'm hearing just go with homepage only, no other data really
needed. I'll make that change.
The point was validly raised in a
Denis Barbier wrote:
For translators having a development URL is also useful, because they can
then send up to date translations; it was said that it is then available
from package homepage, but some packages have no homepage and have a
public CVS repository.
I'm not sure what a development
Britton wrote:
I don't like this. The pages listed will end up being wrong half the time
and google can find homepages very well and everybody knows it, so what is
the point in adding this?
Well we already have the links in the copyright files now, so if they're
going to be wrong half the
Josip Rodin wrote:
On Fri, Dec 06, 2002 at 12:33:06PM -0500, Joey Hess wrote:
Package: debian-policy
The dropping of the packaging manual seems increasinly hasty and
ill-thought-out, when important documentation like this turns out to
have been dropped from debian in the process
Josip Rodin wrote:
How about the attached patch?
Looks good to me.
--
see shy jo
pgp42gc2sLVVN.pgp
Description: PGP signature
Package: debian-policy
The dropping of the packaging manual seems increasinly hasty and
ill-thought-out, when important documentation like this turns out to
have been dropped from debian in the process. This should probably go
into the policy manual's appendices.
- Forwarded message from
Michael Lamertz wrote:
I was wandering for a while now why the ExtUtils::Installed module that
comes with perl-modules doesn't work. Some days ago I noticed the
Debian-Perl-Policy which says:
.packlist files should not be installed.
There's no reason given why this is policy, but it
Lukas Geyer wrote:
Fully seconded. (In the sense of implementing this mechanism, fixing
the affected packages and finally making it policy.) This is
especially helpful when packaging programs having an extensive manual
in HTML and some Help button in their menu. It hit me when I was
trying to
Colin Watson wrote:
Seconded, with one proviso: can we standardize on the Compatible Secure
BROWSER Definition from
http://www.dwheeler.com/browse/secure_browser.html instead? This is what
man-db implements for the 'man -H' switch; ESR-style BROWSER variables
will still work as intended, but
Joey Hess wrote:
First of all, it's possible to write a program that uses ESR's BROWSER
without passing the url through the shell. Here is a modification of my
sensible-browser program that does that:
And I have a patch for urlview now, based on ESR's, that while using
system, quotes the url
Massimo Dal Zotto wrote:
I propose also that sensible-browser is registered as preferred or only
handler for text/html and other url mime types. This can obviously be
overriden in personal mailcap files but the debian alternative and the
BROWSER variable should be the preferred control it.
1 - 100 of 654 matches
Mail list logo
