Topic 7: Leaving time stamps unmodified
STATE: APPROVAL
Most of our packages `touch' files in the packaging process (that is, the
modification time of the files gets reset to the current time). It would
be nice if the modification time of the upstream source would be
preserved.
For example,
Topic 3: Guidelines for Motif applications
STATE: APPROVAL
The following policy has been suggested on debian-policy and will become
official unless someone objects:
Guidelines for Motif applications
-
If you package a program that requires a
On Wed, 22 Oct 1997, Santiago Vila Doncel wrote:
-BEGIN PGP SIGNED MESSAGE-
On Thu, 3 Jul 1997, Christian Schwarz wrote:
Every package that includes HTML documentation has to support the
doc-base package (which will be created soon).
Which is the current status of this
Topic 13: Starting daemons in the postinst scripts
STATE: DISCUSSION
The following policy has been suggested:
If a package installs a `daemon' that is usually started via an
/etc/init.d/ script, the package should query the system
administrator after the installation (in the
Part of the opposition to my proposed source packaging format is
that it forces people to use dpkg, which must be run as root.
I have demonstrated in the previous tutorial that it is possible
to still use the packages in user space by using dpkg-deb --extract.
I have since discovered that it is
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 23.10.97 in [EMAIL PROTECTED]:
Ian == Ian Jackson [EMAIL PROTECTED] writes:
Ian I was flabbergasted last night when I saw that Jim had answered
Ian my 14-point `why-not' list point by point. That message was
Ian intended to terminate the
Raul Miller [EMAIL PROTECTED] writes:
Er.. you've not allowed much time for people to comment. I don't think
it's fair to be disappointed.
I know, I'm sorry. It was a long day yesterday, and I got somewhat
flustered by some of the reaction I got (to several things).
I apologize for the way
Hi,
Jim == Jim Pick [EMAIL PROTECTED] writes:
Jim
Now that dpkg-source is able to manage untouched pristine source
when it is well-behaved, this is a step backwards.
Jim Why backwards? Maybe a horizontal step. Actually, I think it's
Jim a bit better, since you can have multiple pristine
Topic 8: Dates in package versions
STATE: APPROVAL
Some upstream sources use a `snapshot date' instead of a real version
number. As these `dates' are used as version id for dpkg it is useful to
make them all use the same format. (It doesn't matter if our version
number _looks_ different than
Topic 4: Announcing new packages before uploading them
STATE: APPROVAL
According to current policy, every upload of a new package to the archive
has to be announced on debian-devel _before_ the package is uploaded to
the master site. However, must developers do not know this yet. That's why
it
Mark Eichin [EMAIL PROTECTED] writes:
Detail: I think installing sources is fundamentally wrong. This is
partly aesthetic, but that is derived from large scale systems
experience -- there's the system, and there are the users, and
building packages is a *user* function, not a *system*
[EMAIL PROTECTED] (Jim Pick) wrote on 22.10.97 in [EMAIL PROTECTED]:
Funny that there has been so much negative reaction -- and nobody has
even bothered to download the samples I put up yet. Most of the debate
so far has just been a knee-jerk reaction to somebody trying to shake
up the
Topic 12: X Window Manager policy
STATE: INPUT
Joey Hess wrote on Mon, 30 Jun 1997 to debian-devel:
I maintain KDE, which includes a window manager, and I've been
wondering how
other window managers handle registering themselves in
/etc/X11/window-managers. So I took a look
Christian Schwarz [EMAIL PROTECTED] writes:
Topic 16: New source package format
STATE: POSTPONED
The discussion of the following topics has been postponed, until the new
source package format is discussed:
* source dependencies
* new control fields (Author, Upstream-Site, etc.)
On Thu, 23 Oct 1997 09:00:14 -0700, Christoph Lameter wrote:
: I want to check for opinions one more time before abandoning them.
: If we do that, disrespectful language will be allowed, and obscentity
: will be allowed. Is this really what people want?
No.
I want the gestpo regulating the
From: Andreas Jellinghaus [EMAIL PROTECTED]
rules don't work very well, because you have no punishment, if someone
breaks the rules.
OK. Let me restate the problem.
I want guidelines for:
1. Digesting an individual's postings.
2. Placing an individual on moderation.
3.
It's all very well having `rules', but this is IMO missing the real
question.
If people on the mailing lists get to the point where they're calling
each other names then something has gone wrong. Pointing one or both
at the `rules' and banning them for a bit doesn't seem like a solution
to the
(Oops, I sent this to debian-devel by mistake. I think it belongs on
debian-policy, so I'm sending it here now.)
Majoj (SuperCite undone):
[Ian Jackson:]
I was flabbergasted last night when I saw that Jim had answered
my 14-point `why-not' list point by point. That message was
intended
Topic 2: Serial devices
STATE: APPROVAL
The following policy has been suggested and will become official unless
someone objects: (the rationale will probably be removed since it's too
long for the policy manual)
Serial Devices
== ===
Debian uses the new standard of
I disagree with the following part:
If any package has a
large number of configuration files, (like, for example, inn does),
then a package specific subdirectory under /etc/news should be used
(example: /etc/news/suck
Hi,
I think we may consider preserving the rationale (for this and
any other topic), if for nothing else to answer the questions that
would follow, and to prevent the manual from being a string of do's
and don'ts with no discernible reason.
The C standard used to come with the
Dave Cinege:
In other words Bruce needs a way to justify stifiling people that
endanger his complete domination of the Debian project.
I can see no other reason for this policy as the very *RARE* times
their is any noise on the mailing lists it has been about that.
Dave, please try not to
Ian Jackson [EMAIL PROTECTED] writes:
I was flabbergasted last night when I saw that Jim had answered my
14-point `why-not' list point by point. That message was intended to
terminate the discussion, not start one.
Sorry. Maybe it would have had more effect on me if I read it before
I had
We already do, when you run dpkg-source --build, it makes a .orig.tar.gz
file, a .diff.gz file, and a .dsc file.
Actually (though I admit hello-source.deb is a cool hack, it's still a
hack -- and debian has mostly gained it's superiority from getting the
*details* right; that's *why* dpkg is
Manoj Srivastava [EMAIL PROTECTED] writes:
Umm, but if I have to have Debian specific software installed
(or know gory details of the internal structure) in order to check
the upstream source. Like, I can't just upload the Deb file to the
dec alpha at work on a thick pipe to the net,
Hi,
Ian == Ian Jackson [EMAIL PROTECTED] writes:
Ian I was flabbergasted last night when I saw that Jim had answered
Ian my 14-point `why-not' list point by point. That message was
Ian intended to terminate the discussion, not start one.
How very patronizing. You decided that there need
-BEGIN PGP SIGNED MESSAGE-
On 22 Oct 1997, Jim Pick wrote:
444 Oct 22 14:49 README
17506 Oct 22 14:42 hello_1.3-13.1_i386.deb
4306 Oct 22 14:53 src-deb-hello_1.3-1.1_all.deb
88758 Oct 22 14:54 src-orig-hello_1.3-1_all.deb
[ ... ]
drwxr-xr-x jim/jim 0
I was flabbergasted last night when I saw that Jim had answered my
14-point `why-not' list point by point. That message was intended to
terminate the discussion, not start one.
I've read Jim's writings on this subject and he is completely wrong.
I really have better things to do with my time
Without arguing any more, I think it's fair to say that I'd want to
look really hard at some alternatives before the project chooses a
source package format. I'd be listening to Ian Jackson's opinion,
since Ian is the author of dpkg and now has time for the project again.
I'd give a lot of weight
[EMAIL PROTECTED] (Bruce Perens) writes:
I don't think that Debian stuff should go upstream.
Do you offer any justification for that? I think it's a really nice feature
when Debian stuff is built into a software package and no diff is necessary.
Have you used automake? It does a pretty
Jim, it's a clever hack for a morning's work. I don't think it's more than
a mock-up of a real tool to do the job, though. I think we should take the
ideas you've generated and put lots more time and thought into a clean and
elegant design for automated building. I think packaging is just a little
Hi,
I must say, this is pretty impressive. I think we still may
need to work out the dependencies (built vs tar etc), but this seems
to have definite promise.
manoj
--
He who by here and now abandoning sensuality, has gone forth a
homeless wanderer, the search for pleasure
[EMAIL PROTECTED] (Ian Jackson) writes:
In no particular order ...
1. Source packages have different kinds of dependencies to binary
packages.
The stuff is either on your system or not. That is all a dependency
enforces. If you look at it that way, source dependencies are identical
to
Hi all,
I've just repackaged hello using my new proposed source packaging
scheme which does away with dpkg-source and uses just dpkg and
standard .deb files instead.
You can grab the files from:
ftp://ftp.jimpick.com/pub/debian/experimental/hello/
444 Oct 22 14:49 README
17506 Oct
In no particular order ...
1. Source packages have different kinds of dependencies to binary
packages.
2. You can have several versions of the same source package installed
at once.
3. Source packages can be unpacked in various different places.
4. A source packages lives in one or two
Hi,
Jim == Jim Pick [EMAIL PROTECTED] writes:
Jim [1 text/plain; US-ASCII (7bit)] Manoj Srivastava
Jim [EMAIL PROTECTED] writes:
Umm, but if I have to have Debian specific software installed (or
know gory details of the internal structure) in order to check the
upstream source. Like, I can't
From: Jim Pick [EMAIL PROTECTED]
Most of the opposition appears to be based on the fact that I have
violated some aesthetic
This is on target. There is indeed an aesthetic that is an important
part of software architecture. The best software is not simply
functional, but beautiful. Much that we
Hi,
I think this topic (choosing packages which were supposed to
be installed) has come up before, and there was a list of packages
floating around; however, choosing required, important, and standard
packages should also do it.
That means, currently, 133 packages (from the
Paul,
Actually, I've said a number of things that I would not be saying on
the list if we returned to the rules of discourse the project used in
years past. I think that would be for the best.
Think of it as an intelligence test. If someone isn't smart enough to
be able to communicate any idea
From: [EMAIL PROTECTED] (Ian Jackson)
You might also find that becoming a developer would enhance your credibility.
There's a little trust issue standing in the way of that, I fear.
Bruce
--
Can you get your operating system fixed when you need it?
Linux - the supportable operating
Using dpkg this way is great for my proposed source packages, but it is
also useful for any Debian package you might want to install in
user space only.
Clever -- but an amazing kludge :-) Remember that it's ok for this to
be hackish for installing debian packages in user space because
that's
|Ronald The real question is: do we want rules or do we trust that
|Ronald everyone will behave as mature individuals.
|
| I think that past experience shows that peope can't be
| expected to behave as mature individulas, at least not all people,
| all of the time.
That's what I said in the
a) if someone looks for documentation, she changes the directory to
/usr/doc/package, and looks what is in there. so people will not find
documentation in /usr/doc/LANG/locale
b) for one file a directory isn't necessary, in my opinion.
/usr/doc/package/file.locale is ok for me.
locale should be
On Thu, Oct 23, 1997 at 10:53:39PM +0200, Christian Schwarz wrote:
2. Serial devices
This point was also adressed in Brian White's Upcoming Debian Releases
document
(http://www.debian.org/Lists-Archives/debian-devel-9709/msg00042.html).
Could you please explain how you see the relation
Kai Henningsen wrote:
[EMAIL PROTECTED] (Fabrizio Polacco) wrote on 23.10.97:
Disrespectful language and obscentity disqualify only those that use
them. Ignoring them is the right thing to do, IMO.
IMO, it depends entirely on the situation.
Yes, it's true and I agree.
I suppose I
On Thu 23 Oct 1997, Christian Schwarz wrote:
Topic 13: Starting daemons in the postinst scripts
like my proposal to topic #12 :
if you want to query the admin, please recognize some special file or
variable e.g. /etc/dpkg/fastconfig, do not start the daemon, and
add a line to a log file, so
Please tell me where I am wrong.
your create complexity where there is none.
source handling works very fine for me, and i simply do not understand
why you add this complexity, like managing sources as root.
i only see the disadvantages.
so : please not show me example code, please show me
Manoj Srivastava [EMAIL PROTECTED] writes:
I think this topic (choosing packages which were supposed to be
installed) has come up before, and there was a list of packages
floating around; however, choosing required, important, and standard
packages should also do it.
But as you say, that's
Hi,
Andreas == Andreas Jellinghaus [EMAIL PROTECTED] writes:
Andreas On Thu 23 Oct 1997, Christian Schwarz wrote:
Topic 4: Announcing new packages before uploading them
Andreas we should stop announcing and let a script on master do this.
This is a separate issue. Maybe the policy
Hi,
Andreas == Andreas Jellinghaus [EMAIL PROTECTED] writes:
Some people suggested to have an extra directory level for the
documentation file format (e.g. 'HTML/'). I suggest to postpone the
discussion about this sub-topic until we discuss the `documentation
policy'. (Until then, maintainers
Hi,
Santiago == Santiago Vila Doncel [EMAIL PROTECTED] writes:
Santiago * We shall consider upstream sources using 2-digit years as
Santiago an oddity.
Ok.
Santiago This should be considered as a bug (wishlist),
I object. This versioning scheme may need *one* epoch, in the
Hi,
James == James Troup [EMAIL PROTECTED] writes:
James (Hmm, Manoj, why does make depend on libelfg0 for i386? It
James doesn't for m68k and appears to work)
Auuugh. It is the old bug 7807 resurfacing
again!. configure thinks that like Solaris, Linux needs -lelf. I'll
need to fix
On Thu, 23 Oct 1997, Bruce Perens wrote:
From: Christian Schwarz [EMAIL PROTECTED]
REF: cf. #7890, cf. #11095
Are these article numbers or something? They would not be the same on my
system as on yours.
No, these are bug reports:
#7890: Policy manual contradicts itself about
To the rest of the list: We've been seeing a fair amount of noise
recently, whether of the kind quoted above, or miscellaneous user
questions to debian-devel (of which we've had a couple recently), or
whatever.
I propose that if we get much more we close the debian-policy and
debian-devel
-BEGIN PGP SIGNED MESSAGE-
On 24 Oct 1997, Manoj Srivastava wrote:
Santiago This should be considered as a bug (wishlist),
I object. This versioning scheme may need *one* epoch, in the
year 2000, if and only if the upstream author continues with the
version scheme then (the
[EMAIL PROTECTED] (Jim Pick) wrote on 23.10.97 in [EMAIL PROTECTED]:
Please tell me where I am wrong.
In my head, at least, I haven't found a single flaw in my proposal.
Maybe there is a flaw, and the point just hasn't been driven home
to me yet.
Most of the opposition appears to be based
Andreas Jellinghaus [EMAIL PROTECTED] writes:
Please tell me where I am wrong.
your create complexity where there is none.
source handling works very fine for me, and i simply do not understand
why you add this complexity, like managing sources as root.
1) I see much less complexity:
57 matches
Mail list logo
