Re: Bug#43787: PROPOSAL] changing policy on compiling with -g .. a better way
On Wed, Sep 01, 1999 at 04:47:37PM -0700, Chris Waters wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > I wondered if anyone else has an opionion on which of these to choose. > > Either one works for me, but I think the first one is probably needed > > since some builds just can't be changed sensibly. > > It worries me that we're going to become *very* dependent on a > specific version of make all of a sudden. I've tried fairly hard to > keep GNUisms out of my rules files (though I won't swear that I've > succeeded entirely). That's a good point, but far too late to talk about since our rules files are cluttered with Gmake'isms already :) Which is ok with me since it's are only true choice. The thing is though that the examples are GNU'ish, but the maintainers implementation can be whatever she wants so long as it abides by env var. > A simpler (though less comprehensive) solution would be to allow some > way to pass the -g flag explicitly, through standardized variables. > Something like: > > CC_DEBUG=-g dpkg-buildpackage This is possible with this setup already: DEB_BUILD_OPTIONS=debug dpkg-buildpackage > There are limitations to this approach; I mention it merely for > completeness' sake. Otherwise, I prefer the first of Manoj's > suggestions. It seems simpler, and I'm a big believer in simplicity. > And Ben's point seems like a good one too. Noted Ben
Re: Bug#43787: PROPOSAL] changing policy on compiling with -g .. a better way
Ben Collins <[EMAIL PROTECTED]> writes: > On Wed, Sep 01, 1999 at 04:47:37PM -0700, Chris Waters wrote: > > A simpler (though less comprehensive) solution would be to allow some > > way to pass the -g flag explicitly, through standardized variables. > > Something like: > > > > CC_DEBUG=-g dpkg-buildpackage > This is possible with this setup already: > DEB_BUILD_OPTIONS=debug dpkg-buildpackage Yes, yes, yes. The syntax of how to invoke it was not the important part. But something like CC_DEBUG would use simple variable substitution, not complex (and unportable) `if' tests and substring extractions. The CC_DEBUG approach might help avoid dependencies on Gmake. OTOH, one would need another option for install, and this approach wouldn't be as general. But it would certainly be simpler. *shrug* -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: /usr/doc transition and other things
On Thu, Sep 02, 1999 at 12:17:35AM +1000, Anthony Towns wrote: > > It was my understanding that this situation could be resolved in the same > > fashion that the man and info transitions were. By making the docs viewing > > programs aware of both the old and new locations, and back porting them > > into slink, the broken tools issue is resolved. > > AFAIK, it's just not possible to make Apache (and other web browsers) > make both /usr/doc and /usr/share/doc accessible at the one > http://localhost/doc URL. Some of us consider http://localhost/doc to be a case of TMI (Too Much Information) resulting in potentially bad consiquences. While I'm no fan of security by obscurity, you don't need to let the whole world know that you forgot to lock your front door and will be at work until 6pm Apache defaults to having /doc readable by only localhost, but in reality if you want to read docs by web browser you should probably be using dwww anyway which CAN deal with both since it's a perl CGI and could easily build a composite listing of both /usr/doc and /usr/share/doc. JMO,FWIW... -- Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -- "Lord grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to hide the bodies of the people I had to kill because they pissed me off." pgp1D6nNoLcPt.pgp Description: PGP signature
Re: /usr/doc transition and other things
"Joseph" == Joseph Carter <[EMAIL PROTECTED]> writes: Joseph> Apache defaults to having /doc readable by only localhost, but Actually its still world-browsable, since thats easiest (and policy implies it). There are open bugs against this though. netgod i'm trying to convince some netcom admins i know to convert to Debian from RH, netgod, but they are DAMN stubborn why RH users so damned hard headed? it's the hat -- Seen on #Debian
Re: [PROPOSAL] changing policy on compiling with -g .. a better way
> Umm, since the intent is not to make the old way of doing things > incorrect, we can do one of two things. Here are psuedo patches that > detail the approaches. (I personally prefer the second approach). The second one looks fine (except some typos). Roman
Re: [PROPOSAL] changing policy on compiling with -g .. a better way
> Should these packages built with BUILD_DEBUG turned on have a > different name (i.e. libgtk1.2-dbg) than the standard packages? Is > there an easy way to do this other than replicating control file > entries? Hmm... I'd say they shouldn't. They have the same functionality as the non-debug packages, the only difference is that the binaries are bigger. And they're usually built only for local use. Roman
Re: Bug#43787: [PROPOSAL] changing policy on compiling with -g .. a better way
> This is the final form (or, at least, I am done with this). I am > forwarding this to bugs.debian.org My ok again for the second variant. Roman
Re: Bug#43787: PROPOSAL] changing policy on compiling with -g .. a better way
> It worries me that we're going to become *very* dependent on a > specific version of make all of a sudden. Why? Where? The only thing that's GNU make specific is the variable defintion as a dependency, i.e. the suggested implementation of the build-debug target. But that's only a recommendation, you don't need to use it. Roman
Re: uid/gid - comments?
On Tue, 31 Aug 1999, Raphael Hertzog wrote: > No problem, but you could try to do something realistic and logical. I did. I read policy, asked base-passwd maintainer for static ids and got no response at all. Then I asked here, in the hope to get things in order, what we do right now, by this discussion. I'm just disappointed by being suggested "use adduser, and if it fails, it gives you error code", when I've asked for reasonable solution of such possible failures. > On the initial install you check if the ups account does already exist. > You check its uid : if < 1000 then it's a system uid, you can probably use > it for your package. If > 1000 then you complain loudly and make the > installation fail. Give an explanation on stdout (and in README.Debian). I'm looking for a clean solution and according change in policy. If I was to speak of probabilities, I'd just put there static "91". > Instead of having an harcoded name you use ups as a default name but > you make it configurable (command line options or config file). And in > your script you first try ups and then ups2 (if ups was already taken) > and so on. When you've found your name, you put it in the > configuration file and that's it ! You've solved your problem. I did see this solution. I just couldn't believe this is what we want all the packages with system uid/gid to do. Will we really force _this_ behavior on qmail, postgres, mysql and all the others with static ids? To me, even keeping static ids seems better solution. But since static ids are no longer assigned (despite policy), there should be some reasonable way out of this and we should find it. -- jozef :-) Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: uid/gid - comments?
On Wed, Sep 01, 1999 at 10:40:38AM +0200, Andreas Jellinghaus wrote:
> > This is common enough... should we perhaps create a system wide file, that
> > maps default {user,group}names to local {user,group}names?
> >
> > eg, in /etc/local_names:
> > mysql mysql
> > ups ups2
>
> no, please do not add another level of indirection.
> most daemons have configureable user id's anyway.
Yes, but they're configurable at build time, which is problematic if the
uid/gid is already taken on the system on which they're installed.
> it can go wrong and it will. for example with updateing slink
> to potato and installing new potato packages - nothing can prevent
> that i might have created a user id, that is reserved in potato.
Umm... the entire point of this proposal is to avoid actually needing to
reserve id's, and prevent the problem you mention.
> and if you realy want, there is always a way to shoot yourself.
Of course; I just think that this solution makes it harder to shoot
yourself than what we have now.
> so we should better find a smart way to handle this.
>
> for the novice user: they either may not use the package or have to remove the
> user id before installing the package.
>
> for the experienced user: take care of it yourself.
> changeing permissions (suid/sgid on apps and /var/lib/* stuff) is
> not that difficult. editing for example http.conf to use a different
> user id is also easy.
But sometimes they're compiled directly into the binary.
> anyway, i only expect less than 0.1 percent of debian users to suffer
> from these problems. on the other side, if you add another level of
> indirection, then everyone will have to learn that new concept and live
> with it.
No-one will have to learn the concept if it doesn't affect them (it all
happens in the magic {pre,post}{inst,rm}'s). If it does affect them then
it would seem that they'd prefer such a system which makes it possible to
work around their problem without changing existing user ids or recompiling
packages.
Or if you were referring to developers, then I think that we need some sort
of policy about this anyway (better than the current situation with mysql,
for example), and creating the mentioned scripts would probably make these
developer's lives easier, not harder.
> please remember why windows is not good. too many levels of indirections,
> unknown strange concepts and that stuff is part of the windows problem.
>
> always remember: keep it simple !
But increased organization _is_ simplicity. Every package doing something
that's broken in different and exciting ways is not.
-- Nathaniel
Re: Bug#43787: PROPOSAL] changing policy on compiling with -g .. a better way
> > It worries me that we're going to become *very* dependent on a > > specific version of make all of a sudden. > > Why? Where? The only thing that's GNU make specific is the variable > defintion as a dependency, i.e. the suggested implementation of the > build-debug target. But that's only a recommendation, you don't need > to use it. And note that we're only messing with debian/rules, which is Debian-specific anyway. And Debian is committed to GNU make. This shouldn't be a problem. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Multibyte encoding - what should a package provide?
[Reference: bug#43702] I have had a request for a postgresql package with multibyte support. Such support would enable postgresql to store data in different character sets, so that data in Russian, Greek, Chinese or other scripts could be stored and sorted properly. There are several issues that I would like clarified: 1. Whether to have separate packages with and without multibyte support? In one sense, this is only an issue because of Anglo-Saxon parochialism. I'm inclined to say: of course I should enable multibyte support without splitting the package, since the majority of the world's population will need it, and many even of the English-speaking world may sometimes need to record data in other character sets. (Without multibyte support, it is not possible to specify a character set for a database.) postgresql already includes locale support, which has some detrimental effect on performance. 2. Which character set to make the default? The choice here seems to be either Unicode (UTF-8) or SQL-ASCII. Most other choices limit me to the character set of a few languages. Of course, SQL-ASCII is effectively the character set for American English, so perhaps Unicode is the only choice. 3. Whether Debian policy has anything to say on the matter? As more packages are internationalised, it will become more important for us to have a consistent policy. References: The above bug contains some discussion of this from the postgresql list, and other messages may be seen in the archive of the psql-hackers mailing list in the thread "Implications of multi-byte support in a distribution" at http://www.PostgreSQL.ORG/mhonarc/pgsql-hackers/1999-08/msg00642.html and http://www.PostgreSQL.ORG/mhonarc/pgsql-hackers/1999-09/msg0.html See also: /usr/doc/postgresql-doc/README.mb.gz (postgresql-doc package) -- Vote against SPAM: http://www.politik-digital.de/spam/ Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 "But God said to him, You fool! This very night your soul is required of you; and now who will own what you have prepared? So is the man who lays up treasure for himself, and is not rich toward God." Luke 12:20,21
Re: /usr/doc transition and other things
Dale Scheetz wrote: > It was my understanding that, like the man and info transitions, these > problems are resolved by giving the tools the knowledge of the dual > locations. Our current binary dependencie scheme is sufficient to deal > with "incremental upgrades". Those packages that use the new location only > need depend on the "fixed" version of the viewer for a smooth incremental > upgrade. This was my initial proposal to debian-policy, oh, a month ago. People shot it down for various silly reasons. Feel free to adopt it, that'd make me happy. But it has currently *not* been agreed on, and if the committe doesn't do something to address it, it will not be addressed. -- see shy jo
