Hey,
I've found that nice stuff recently and just wanted to ask what do you
think about it? Check it out here https://is.gd/MypJ0j
My Best, Goswin von Brederlow
From: developers-reference [mailto:developers-refere...@packages.debian.org]
Sent: Monday, August 07, 2017 8:05 AM
To
Peter Pentchev writes:
> On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
>> On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
>> > From discussion on IRC earlier this evening, it looks like the most
>> > pragmatic approach will be to get the apt and aptitude sbuild
>> > r
Roger Leigh writes:
> On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote:
>> On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
>> > On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote:
>> > > I disagree here.
>> > > Alternatives in build-* relationships *are*
Steve Langasek writes:
> Hi there,
>
> On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote:
>
>> The Multiarch specification only covers libraries and does not
>> specifically deal with include files.
>
>> To make multiarch useful for cross-building as well as co-installation of
>> libraries
Raphael Hertzog writes:
> On Sun, 03 Apr 2011, Russ Allbery wrote:
>> My inclination is to second this, but I want to make sure that we've
>> answered your and Julien's objections first.
>
> And for complete reference, dpkg accepts those version in
> /var/lib/dpkg/status (so that dpkg still works
Steve Langasek writes:
> On Fri, Apr 08, 2011 at 07:44:27PM +0200, Goswin von Brederlow wrote:
>> > On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote:
>
>> >> The Multiarch specification only covers libraries and does not
>> >> specifically de
Roger Leigh writes:
> On Tue, Jun 07, 2011 at 11:14:14AM +0200, Tollef Fog Heen wrote:
>> ]] Steve Langasek
>>
>> Hi,
>>
>> | 4) Turn on direct use of 'debian/rules build-arch' on the autobuilders for
>> | all packages in unstable and experimental immediately, with no fallback
>> | if
Ian Jackson writes:
> Goswin von Brederlow writes ("Re: Bug#664257: multiarch tuples are not
> documented/defined"):
>> It is a bug in Debian: The multiarch tuples are not documented/defined
>> in Debian.
>
> They are now documented on the wiki, as previousl
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Lucas Nussbaum]
>> - the number of parallel jobs should be specified by the developer
>> building the package. There's no way to automatically guess the
>> value in a sensible way, since it doesn't depend only on the number
>> of CPUs but also o
Gabor Gombas <[EMAIL PROTECTED]> writes:
> On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote:
>
>> What about these clauses as a Policy amendment?
>>
>> 1. If a library *only supports the retrieval of FOO_LIBS and / or
>> FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part o
Manoj Srivastava writes:
> I am wondering which is of more use to the end users as well: I
> can always get the sources of the package I have already on my disk
> from Debian, but getting the latest munged source seems more useful to
> me.
Full ACK. The way to get the current upstream
Raphael Hertzog writes:
> On Fri, 13 Mar 2009, Manoj Srivastava wrote:
>> 3. dpkg-buildpackage is probably the wrong place to put this solution
>> in.
>
> Why?
>
>> The fact that dpkg-buildpackage's setting the variables is not
>> easily configurable, and presents to make as though
Package: debian-policy
Severity: normal
Hi,
Debian policy 10.2 Libraries says:
| Packages containing shared libraries that may be linked to by other
| packages' binaries, but which for some compelling reason can not be
| installed in /usr/lib directory, may install the shared library files
| in
Kurt Roeckx writes:
> On Mon, Mar 16, 2009 at 10:44:49AM -0700, Russ Allbery wrote:
>> Steve Langasek writes:
>>
>> > This recommendation needs to be elminated entirely. It is *not* ok for
>> > packages that provide libraries to stick extra linker paths in the
>> > global configuration, whethe
Raphael Hertzog writes:
> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > achieve.
>>
>>
Steve Langasek writes:
> On Wed, Mar 18, 2009 at 12:52:39AM +0100, Rafael Laboissiere wrote:
>> * Bill Allombert [2009-03-17 17:02]:
>
>> > What is the rational for making the library private in the first place ?
>
>> In the case of the octave package, it is a decision of the upstream
>> authors
Holger Levsen writes:
> Hi,
>
> while testing the archive with piuparts I found a failure reported by
> piuparts, that after purge /var/games existed on the system while it wasnt
> there before installing+purging the package.
>
> See http://piuparts.debian.org/squeeze/fail/slashem-common_0.0.7
Steve Langasek writes:
> On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote:
>> On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
>> > I thought it was generally recognized that it's a Bad Idea to implement
>> > config files using your interpreter's 'include' functionality, but t
Bill Allombert writes:
> On Sun, May 10, 2009 at 09:54:11PM +0200, Raphael Hertzog wrote:
>> On Sun, 10 May 2009, Steve Langasek wrote:
>> > I'm really surprised to see this approach getting traction. To me, this
>> > seems like a significant, unprecedented departure from the kinds of
>> > inter
Jonathan Yu writes:
> Hi:
>
> This is probably a stupid question, but...
>
> On Tue, May 26, 2009 at 11:33 PM, Russ Allbery wrote:
>> Currently, Policy's description of Architecture includes the statement:
>>
>> Â Â In the main debian/control file in the source package, or in the
>> Â Â source
Russ Allbery writes:
> Currently, Policy's description of Architecture includes the statement:
>
> In the main debian/control file in the source package, or in the
> source package control file .dsc, one may specify a list of
> architectures separated by spaces, or the special values
"Adam D. Barratt" writes:
> On Thu, 2009-06-04 at 14:14 +0200, Bill Allombert wrote:
>> Consider this example: the safe "printf" way to do
>> echo $BAR
>> is
>> printf "%s\n" "$BAR"
>>
>> (in case BAR hold a value like BAR="%s a")
>> So printf is slightly unwiedly to use and it can create
>> for
sean finney writes:
> On Thu, Jul 02, 2009 at 09:44:50AM -0500, Manoj Srivastava wrote:
>> The question is, why should we change something so deeply
>> deployed as package postinst API without compelling reasons that the
>> postinst should treat an upgrade differently from a reconfigure
Russ Allbery writes:
> Martin Zobel-Helas writes:
>
>> i would like to propose an addendum to section 7.7 of the Debian Policy:
>>
>> | Build-Depends and Build-Depends-Indep must not depend directly or
>> | indirectly on packages which provide network services.
>
> Package maintainers have littl
Manoj Srivastava writes:
> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>
>> Manoj Srivastava wrote:
>>> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
which is short since the format is basically that of .d
Manoj Srivastava writes:
> On Fri, Aug 21 2009, Russ Allbery wrote:
>
>> Steve Langasek writes:
>>> On Fri, Aug 21, 2009 at 03:47:24PM -0700, Russ Allbery wrote:
>>
It looks good to me as a first step. Seconded, with the caveat that we
probably don't want to release this with Policy u
Raphael Geissert writes:
> Bill Allombert wrote:
>> 3) If a package is lacking debian/README.source, then one should expect
>> that the source is ready to be used. If it not the case, even an empty
>> debian/README.source is better than none.
>>
>
> What would an empty README.source file mean?
>
Vincent Danjean writes:
> Kurt Roeckx wrote:
>> On Fri, Nov 13, 2009 at 08:51:42PM +0100, Bill Allombert wrote:
>>> I would suggest a new lintian tag 'rpath-outside-usr-lib' that flags
>>> packages with rpath pointing outside /usr/lib and /lib. This clearly
>>> warrant a REJECT but have much less
Hi,
Steve Langasek (vorlon) informed me on irc that the policy changes for
multiarch are commited now but not yet released and this is now blocking
the progress of multiarch as in the case of eglibc:
11:21 < vorlon> mrvn: the change is committed; talk to the policy maintainers
about gett
Hector Oron writes:
> Hello Goswin,
>
> 2010/1/25 Goswin von Brederlow :
>> Steve Langasek (vorlon) informed me on irc that the policy changes for
>> multiarch are commited now but not yet released and this is now blocking
>> the progress of multiarch as in the
martin f krafft writes:
> also sprach Steve Langasek [2010.01.26.0007 +1300]:
>> I don't see any reason for the package manager changes to block
>> the Policy update. Even if the multiarch field is not yet
>> supported, it doesn't hurt anything to have packages using those
>> directories (*if*
Hector Oron writes:
> Hi,
>
> 2010/1/25 Bill Allombert :
>> OK, I will release the new policy soon if there is no objection from the
>> other maintainers. Sorry I did not notice there were normative changes.
>
> OK, revert my objection. Thanks!
>
> Regards,
Thanks all around.
MfG
Goswin
Simon McVittie writes:
> While trying to prepare a multiarch version of libdbus I received some
> conflicting advice about how much of the multiarch proposal is already
> allowed by Policy, so I've prepared a multiarch version of a rather
> simpler library (libgfshare) as a starting point.
>
> Do
Russ Allbery writes:
> Mike Hommey writes:
>
>> I first though having dh_makeshlibs do the right thing would be good
>> enough, but that would also put an unnecessary burden on those that
>> don't use debhelper.
>
> Is there any way that dpkg-gensymbols could do it (perhaps with extra
> argument
Russ Allbery writes:
> martin f krafft writes:
>
>> I still think set -e is a good idea, but I realise it boils down to
>> preference. If your experience is representative, then it's probably
>> better to advocate not setting set -e in init scripts.
>
>> What about maintainer scripts?
>
> It's a
Stefano Zacchiroli writes:
> Package: debian-policy
> Severity: wishlist
> Version: 3.8.4.0
>
> [ For the full context, see the -devel thread starting at
> http://lists.debian.org/debian-devel/2010/03/msg00038.html ]
>
> On Thu, Mar 04, 2010 at 01:12:26PM -0800, Russ Allbery wrote:
>> > Russ, w
Russ Allbery writes:
> Bill Allombert writes:
>> On Thu, Mar 04, 2010 at 11:00:45PM +0100, Stefano Zacchiroli wrote:
>
>>> Currently, packages ships file checksums which are computed at package
>>> build time by the means of dh_md5sums (usually), and stored under
>>> /var/lib/dpkg/info/*md5sums.
Russ Allbery writes:
> Raphael Hertzog writes:
>
>> Russ, dpkg-gensymbols could be modified to do that shlibs
>> generation. Feel free to file a wishlist request against dpkg-dev.
>
> Will do. Thanks! I agree with Mike that for people already maintaining a
> symbols file, this would be very us
Bill Allombert writes:
> On Wed, Apr 21, 2010 at 09:10:54AM +0200, Raphael Hertzog wrote:
>> Package: debian-policy
>> Severity: wishlist
>>
>> The desired outcome is that all package grab the values directly from
>> dpkg-buildflags and that we can stop exporting the variables from
>> dpkg-build
owngrade:
m...@frosties:~/t% dpkg -s bar
Package: bar
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 44
Maintainer: Goswin von Brederlow
Architecture: all
Version: 2b
Replaces: foo (<= 1)
Breaks: foo (<= 1)
Description: dummy foo
dummy package to test
m...@frosties
"Eugene V. Lyubimkin" writes:
> Package: debian-policy
> Version: 3.8.4.0
> Severity: normal
>
>>From Debian policy, paragraph 7.3:
>
> -8<-
> If the breaking package also overwrites some files from the older
> package, it should use Replaces (not Conflicts) to ensure this goes
> smoothly.
> ->8-
Steve Langasek writes:
> On Fri, Apr 23, 2010 at 09:27:32AM +0200, Raphaël Hertzog wrote:
>> I stumbled upon policy 7.4:
>> > A Conflicts entry should almost never have an "earlier than" version
>> > clause.
>> > This would prevent dpkg from upgrading or installing the package which
>> > declar
"Eugene V. Lyubimkin" writes:
> Goswin von Brederlow wrote:
>> No. They can trivially see if two packages have conflicting files. Ther=
> e
>> is a Replaces entry in the package.
> Two package with conflicting files may not have Replaces if they are tota=
> ll
"Eugene V. Lyubimkin" writes:
> package debian-policy
> retitle 578852 clarify installation of package having reverse-Replaces
> thanks
>
> Eugene V. Lyubimkin wrote:
> [...]
>
> My mail client somewhy garbaged the output in my previous message, sorry for
> that.
I think the title was fine and
Guillem Jover writes:
> Hi!
>
> On Fri, 2010-04-23 at 10:51:56 +0200, Goswin von Brederlow wrote:
>> Package: debian-policy
>> Version: 3.8.4.0
>> Severity: normal
>
>> to test the actual behaviour of dpkg for this situation I created the
>> follow
Package: debian-policy
Version: 3.8.4.0
Severity: normal
Hi,
Debian Policy 8.6 'Dependencies between the library and other packages
- the shlibs system' seems seriously out of date as it makes no
mentioning of symbols files at all.
Other than the lack of documentation of the superior system I fi
Package: debian-policy
Version: 3.8.4.0
Severity: normal
Hi,
in May there was a discussion about the right use of Breaks or
Conflicts as part of Bug#582423, e.g.
http://lists.debian.org/debian-ctte/2010/05/msg00012.html
Since then I've noticed at least 3 people on #debian-devel asking
question
"Eugene V. Lyubimkin" writes:
> Seconded.
>
> Specifically, Policy now allows use Breaks, not Conflicts if two
> packages has a file conflict. I consider it as a regression - a
> high-level package manager cannot assume anymore that two packages
> having Breaks can be installed (temporarily) with
"Eugene V. Lyubimkin" writes:
> [ sorry for not proper 'mail-reply', used wrong mail address before ]
>
>> Huh? The presense of Replaces allows the two to be both unpacked. The
>> Repalces specifically disables the file conflict.
>
> Replaces is one-way dependency, Breaks is two-way one. If I unp
Simon McVittie writes:
> On Sun, 22 Aug 2010 at 20:22:17 +0200, Sebastian Andrzej Siewior wrote:
>> "This means that architecture restrictions must not be used in binary
>> relationship fields for architecture-independent packages (Architecture:
>> all)."
>
> This just forbids the following:
>
>
Andreas Barth <[EMAIL PROTECTED]> writes:
> Hi,
>
> I made a proposal of an updated deb format definition. I based that on
> the manpage deb (part of dpkg-dev), and on reverse engineering of
> dpkg-deb/build.c. I hope I've written the standard in a right and easy
> to understandable way. I did (b
Nathanael Nerode <[EMAIL PROTECTED]> writes:
> I was surprised to discover that the standard rules for Debian
> revision numbers
> (maintainer revisions contain no dots;
> source NMUs contain one dots;
> binary NMUs contain two)
> are not in Policy, but only in the Developer's Reference.
>
> Thi
Loïc Minier <[EMAIL PROTECTED]> writes:
> On Mon, Nov 21, 2005, Goswin von Brederlow wrote:
>> Since common practice for NMU, binNMU and security versions are
>> flawed, as in they don't sort right with dpkg --compare-versions, I
>> would rather see a new sch
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Mon, Nov 21, 2005 at 03:23:17PM +0100, Goswin von Brederlow wrote:
>> Nathanael Nerode <[EMAIL PROTECTED]> writes:
>
>> > I was surprised to discover that the standard rules for Debian
>> > revision numbers
Loïc Minier <[EMAIL PROTECTED]> writes:
> On Wed, Nov 23, 2005, Goswin von Brederlow wrote:
>> What is your point?
>>
>> In my example the binNMU done _BEFORE_ the security release sorts
>> _AFTER_ the security release. So updates will not get the fix.
>
>
Russ Allbery <[EMAIL PROTECTED]> writes:
> Hello folks,
>
> I have proposed a modification for Policy that will permit wrapping in the
> following fields in debian/control:
Wouldn't it be better to require all tools to accept multi-line fields
for any field? And recommend using it for long lines
Bill Allombert <[EMAIL PROTECTED]> writes:
> Hello Wouter,
>
> First thank for bringing back this issue, however...
>
> On Tue, May 23, 2006 at 10:17:01PM +0200, Wouter Verhelst wrote:
>> The last post to this bug was done on 2004-08-23, which is ages ago. I
>> think it's safe to say that Bill's p
Bill Allombert <[EMAIL PROTECTED]> writes:
> On Thu, Jun 08, 2006 at 01:50:37PM -0700, Chris Waters wrote:
>> On Thu, Jun 08, 2006 at 02:48:34PM +0200, Bill Allombert wrote:
>> > On Thu, Jun 08, 2006 at 04:28:36AM -0700, Chris Waters wrote:
>> > > Date: [...] Talk to the dpkg maintainers--
>> > >
Lars Wirzenius <[EMAIL PROTECTED]> writes:
> pe, 2006-06-09 kello 22:04 +0200, Bill Allombert kirjoitti:
>> Sometimes, the changelog will tell you the package was last changed 3
>> month ago while actually it was changed yesterday and build and uploaded
>> today. This can lead you to go on a wild-
Andreas Barth <[EMAIL PROTECTED]> writes:
> * Adeodato Simó ([EMAIL PROTECTED]) [060610 03:11]:
>> * Margarita Manterola [Thu, 08 Jun 2006 23:35:54 -0300]:
>>
>> > So, in any case, I'd encourage you to patch dpkg to handle a new
>> > "Homepage" field, and submit the patch. Once this is being use
David Weinehall <[EMAIL PROTECTED]> writes:
> On Fri, Jun 09, 2006 at 10:04:48PM +0200, Bill Allombert wrote:
>> On Thu, Jun 08, 2006 at 01:50:37PM -0700, Chris Waters wrote:
> [snip]
>> > Anyone who makes a change and doesn't put it in the changelog should
>> > be chastised. But I agree, it does
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> One question to ask is perhaps whether splitting the build dependencies
> into several sets is useful at all, considering that the current state
> of having effectively only one useful set has persistent for such a
> long time.
>
> Not a lot of peo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>> On the other hand the savings can be huge. Think about how many
>> packages install latex and fonts and generate the documentation
>> needlessly during build. Installing and purging latex a
Guillem Jover <[EMAIL PROTECTED]> writes:
> On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote:
>> Package: debian-policy
>> Severity: normal
>
>> [Side note: Buildds/dpkg-buildpackage has no robust way of telling if
>> the optional build-arch field exists and must call build. This is
>>
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On 18 Jun 2006, Goswin von Brederlow outgrape:
>
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>
>>> Goswin von Brederlow wrote:
>>>> On the other hand the savings can be huge. Think about
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On 16 Jun 2006, Goswin Brederlow stated:
>
>> the current use and definition of Build-Depends/Conflicts[-Indep] in
>> policy 7.6 don't match. Both use and definition also greatly reduce
>> the usefullness of these fields. This issue has come up again
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>
>> Sbuild explicitely, by design, only looks at build-depends. So in order
>> for build-depends to be useful at this time if you want a package to
>> build, you need to list mostly everything in build-d
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Previously, any new feature in dpkg which goes into release
> foo gets into policy in release foo + 1. Is there a compelling
> reason to diverge from this practice?
>
> manoj
Isn't that for binary packages because otherwise you can
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Stephen Gran <[EMAIL PROTECTED]> writes:
>
>> This one time, at band camp, Thomas Bushnell BSG said:
>>> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>>>
>>> > Sbuild explicitely, by design, only looks at build-depends. So in order
>>> > for build-
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Thomas Bushnell BSG said:
>> Whenever this has been asked in the past, sbuild has simply declared
>> "this is how I want to do it." I have no idea why.
>>
>> If there is no technical reason for sbuild to behave this way, and
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Tue, Jun 20, 2006 at 07:52:01PM -0700, Thomas Bushnell BSG wrote:
>> Stephen Gran <[EMAIL PROTECTED]> writes:
>>
>> > This one time, at band camp, Thomas Bushnell BSG said:
>> >> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>> >>
>> >> > Sbuild exp
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> Therefore, if the implementation of sbuild differs from whatever Policy
> happens to claim, then Policy is simply wrong.
As state before policy is wrong.
That doesn't mean we can't change both policy and sbuild at the same
time to something that both
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Wed, Jun 21, 2006 at 02:08:57PM +0200, Goswin von Brederlow wrote:
>> Policy says Build-Depends-Indep must be installed for the build
>> target, which sbuild calls. But sbuild does not install
>> Build-Depends-Indep. Same
Charles Fry <[EMAIL PROTECTED]> writes:
> Hi,
>
> I recently uploaded courierpassd, which wraps some functionality of
> courier-authlib in the popassd protocol. lintian has been warning me
> about the use of rpath, about which I posted on debian-mentors. This
> culminated in the following thread:
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Sat, Jul 15, 2006 at 02:25:49PM +0200, Goswin von Brederlow wrote:
>> Please note that this (rpath) prevents automatic multiarch conversion
>> for packages. Instead of a simple post procesing of the deb files a
>> much mor
Ian Jackson <[EMAIL PROTECTED]> writes:
> Package: debian-policy
>
> ,[ § 7.2 ]
> | In case of circular dependencies, since installation or removal order
> | honoring the dependency order can't be established, dependency loops
> | are broken at some random point, and some packag
Steve Langasek <[EMAIL PROTECTED]> writes:
> If you want to declare a strict versioned dependency from an arch: all
> package to an arch: any package... don't do that, because it will break
> under binNMUs. :)
I only know of one simple way to handle this:
arch:any provides any-package-1.2-3
arch
Lucas Nussbaum <[EMAIL PROTECTED]> wrote:
> With this, apt fails:
> $ apt-cache showsrc qd
> Package: qd
> Binary: libqd2c2a, libqd-dev
> Version: 2.1.200-1
> [...]
> Package: kfolding
> Binary: kfolding, qd
> Version: 1.0.0-rc2-5
As you can see there are two sources that could be what you mean.
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Thu, Jan 18, 2007 at 03:12:12PM +0100, Goswin von Brederlow wrote:
>>
>> In the initial report you mentioned that sbuild has a problem with
>> confusing names like this. Afaik sbuild solely works on source package
>
Guillem Jover <[EMAIL PROTECTED]> writes:
> Hi,
>
> I've been thinking on implementing this for a long time. As
> Robert has presented an implementation to the Architecture
> handling problem that does not convince me at all, so instead
> of just sitting here and criticize his design I've coded mi
Guillem Jover <[EMAIL PROTECTED]> writes:
> Hi,
>
> On another thread, Goswin von Brederlow wrote:
>> Could we automatically define some @linux@ or @any-i386@ variables the
>> same way shlidbs or other substitutions work?
>
> That's exactly what m
sean finney <[EMAIL PROTECTED]> writes:
> On Sun, Jan 30, 2005 at 02:28:01PM +0100, Santiago Vila wrote:
>> So, the common sense says /usr/bin is ok for gettext.sh, not the opposite.
>
> s,common sense,convenience for the author/maintainer,
>
>> If you want to make policy that /usr/bin should only
Santiago Vila <[EMAIL PROTECTED]> writes:
> On Sun, 30 Jan 2005, sean finney wrote:
>
>> think about the purpose path is supposed to serve. the bash man page
>> says PATH is "The search path for commands". it mentions nothing of
>> shell scripts to be included/sourced.
>
> This is from bash(1):
Santiago Vila <[EMAIL PROTECTED]> writes:
> On Sun, 30 Jan 2005, Goswin von Brederlow wrote:
>
>> Where do you want to put gettext.sh? Once in every gettext-base or
>> only once in gettext-base-common?
>
> I don't know, maybe in the same package as GNU.Gettex
84 matches
Mail list logo
