Brian May [EMAIL PROTECTED] writes:
Bredewlow,
You have raised a number of important issues. However I think we need to
wait until Gordon finishes his proposal he is working on until we start
debating again, to ensure that we are all looking at the same set of
issues. Otherwise it gets too
Gordon Matzigkeit [EMAIL PROTECTED] writes:
Brederlow writes:
B It's not quite a port, it's a different operating system. :)
Is a system that uses vim instead of elvis a new port or a new
operating system? My answer is neither, it's just an additional
option for basically the same
Brian May [EMAIL PROTECTED] writes:
...
B When I'm a hurd fan, I can just select debian-hurd and hit the
B download key (together with stabling symlincs) and I have my hurd
B for all my archs.
Why not just use apt?
Because apt won`t run on HPux and it certainly won`t install my alpha
at
On Thu, Apr 15, 1999 at 02:01:29PM -0600, Gordon Matzigkeit wrote:
Now, I guess it would be useful for at least glibc. In that case,
the keyword I like best is `kernel-any' - `linux ^ hurd ^ ...'.
BM Hang on - I think I read you now. You are saying that most
BM programs should
Richard Braakman wrote:
Note that we already have the problem that some source packages build
different sets of binary packages on different architectures. There's
no real support for that; we just wing it. This causes the archive
check scripts to whine at me a lot :-)
Maybe the best way around
Marcus Brinkmann writes:
BM Hang on - I think I read you now. You are saying that most
BM programs should depend on the specific glibc version rather then
BM the kernel.
Nearly every program will depend on the specific glibc soname
(i.e. libc5 or libc6 on Linux, libc0.2 on the Hurd).
On Sun, Apr 18, 1999 at 10:24:55AM -0600, Gordon Matzigkeit wrote:
[excellent explanation snipped]
hwarch == CPU-VENDOR (no OS or kernel)
That makes it very clear, thank you!
So, maybe I should make it `hwarch-i386-pc', to distinguish from
`hwarch-i386-pc98', which doesn't exist yet.
Okay,
Timothy Baldwin writes:
TB I suggest that hwarch-foo can only be installed on hardware foo
TB and provides hwiset-bar for each instruction (sub-)set foo
TB provides.
It would be easier to call `hwiset-*' simply `cpu-*'.
In fact, that is the conclusion that Marcus Brinkmann led me to, and
so
Marcus Brinkmann writes:
MB Okay, this can be addressed when the need arises. i3856 is the a
MB short cut for i386-pc in the meantime.
i3856? Were you just typing too fast, or do you know something I
don't? ;)
--
Gordon Matzigkeit [EMAIL PROTECTED] //\ I'm a FIG (http://www.fig.org/)
On Sun, Apr 18, 1999 at 11:06:51AM -0600, Gordon Matzigkeit wrote:
Marcus Brinkmann writes:
MB Okay, this can be addressed when the need arises. i3856 is the a
MB short cut for i386-pc in the meantime.
i3856? Were you just typing too fast, or do you know something I
don't? ;)
I only
Gordon Matzigkeit wrote:
[Brian, your summary of the idea is nearly perfect. Thanks for taking
the time to explain this in a clear way that I wasn't able to. I
really depend on people such as you to interpret my grunts and
hand-waving and come up with a coherent explanation that makes sense
Richard Braakman wrote:
Gordon Matzigkeit wrote:
[Brian, your summary of the idea is nearly perfect. Thanks for taking
the time to explain this in a clear way that I wasn't able to. I
really depend on people such as you to interpret my grunts and
hand-waving and come up with a coherent
Brian May wrote:
Richard Braakman wrote:
I've read Brian's summary, but I still don't see the point of this
operator. It seems that what you want to accomplish can be
done just as easily with:
Depends: hwarch-${Arch}, ${shlibs:Depends}
You can't say
Depends: hwarch-i386 ^
Richard Braakman writes:
RB I've read Brian's summary, but I still don't see the point of
RB this operator. It seems that what you want to accomplish can be
RB done just as easily with:
RB Depends: hwarch-${Arch}, ${shlibs:Depends}
Thanks for pointing this out. I'll integrate it in the
Gordon Matzigkeit wrote:
[Brian, your summary of the idea is nearly perfect. Thanks for taking
the time to explain this in a clear way that I wasn't able to. I
really depend on people such as you to interpret my grunts and
hand-waving and come up with a coherent explanation that makes sense
to
In article [EMAIL PROTECTED] you write:
Gordon Matzigkeit [EMAIL PROTECTED] writes:
BM When the source package is compiled, the appropriate items from
BM the Nonshared-depends would get moved to Depends.
Or, equivalently, the `||' symbols in the Depends field would be
replaced with the
[Brian, your summary of the idea is nearly perfect. Thanks for taking
the time to explain this in a clear way that I wasn't able to. I
really depend on people such as you to interpret my grunts and
hand-waving and come up with a coherent explanation that makes sense
to other people. ;)]
To
Marcus Brinkmann [EMAIL PROTECTED] writes:
On Thu, Apr 01, 1999 at 10:31:29AM +0200, Brederlow wrote:
I would feel disappointed by such a solution. Seperating out a port will
make all integration efforts harder, and please consider the consequences
for our complete infrastructure
Gordon Matzigkeit [EMAIL PROTECTED] writes:
BM When the source package is compiled, the appropriate items from
BM the Nonshared-depends would get moved to Depends.
Or, equivalently, the `||' symbols in the Depends field would be
replaced with the dependency that was actually used.
I have
On 6 Apr 1999, Gordon Matzigkeit wrote:
Here is a possible way of specifying the information:
Anything that has a `|' in its dependencies means that there is more
than one kind of binary package, so, say the binary packages were
different depending on the kernel you had installed:
Depends:
In article [EMAIL PROTECTED] you write:
BM Just a comment: In the source code for each dependancy (eg CPU)
BM you would have a specification, ie something like:
BM - the source code MUST be recompiled. eg for another CPU.
BM - the source code does not have to be recompiled, but still
BM
In article [EMAIL PROTECTED] you write:
Currently, the only packages that can be shared are the ones that are
placed into `all'. This is the N=1 case.
Marcus Brinkmann's (and I believe also your) temporary solution is to
create `all-linux', and `all-hurd' as well as `all'. This is the N=K
Brian May writes:
BM If I have got this right:
BM So instead of of having *releases* for each combination of
BM release,kernel,cpu
BM You could have a *package* depend on any number of factors (as
BM determined important), eg
BM kernel,cpu,glibcversion,gnomeversion
BM Therefore, grub
I will just indicate one or two points that I disagree with in the
last posts. I have previously stated my full opinion on this mailing
list, anyone can read the archives if they want to. Please forgive
me if I make any mistakes or suggest the same solutions that somebody
has already disputed.
In
(Gordon will want to answer, but I want to clarify some things, too).
On Fri, Apr 02, 1999 at 11:16:39AM +1000, Brian May wrote:
I am not sure why you would want to say that something depends on
an architecture (ie major change involved in the way we think about
packages) when you can do
Brian May writes:
BM What does ABI stand for/mean?
Application Binary Interface. An API is the Application Programming
Interface.
Here are two code snippets with the same API, but different ABIs:
int bar (void);
#define foo bar
and:
int foo (void);
The programmer just calls `foo ()', but
[CCed to debian-devel, since people there are probably interested.]
Brian May writes:
BM I agree. I think of the Hurd as being a replacement kernel for
BM Linux. Technically, I realize this is wrong (GnuMach is the
BM kernel) but I don't care ;-)
I just repeat the mantra ``The GNU Hurd
Whoa, Nellie! I shoulda proofread my message one more time before
sending. ;)
Gordon Matzigkeit writes:
Gord Kernels other than Linuk are *not* second-class citizens.
Sorry folks, this was the *one* time I've ever made a typo when
spelling _Linux_. No offense was intended.
Gord It would
Marcus Brinkmann writes:
MB When the heard does emulate these calls, we can provide Linux,
MB done.
Talk about quantum correlation. I misspelled Linux, and you
misspelled Hurd. ;)
--
Gordon Matzigkeit [EMAIL PROTECTED] //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and
Marcus Brinkmann writes:
MB This is less complex then the current mechanism, because we only
MB need provide and depends, and hopefully not conflicts and
MB replaces.
No package needs Conflicts and Replaces. They are just shorthands for
Provides (given that two packages cannot Provide the
[Okay, I'm getting overexcited. I'll just shut up now, since I'm
going on vacation for the next three days. ;)]
Gordon Matzigkeit writes:
I should have though more before I wrote. Here's what I *meant* to say:
No package needs Conflicts and Replaces. They are just shorthands for
Exclusive
Gordon Matzigkeit [EMAIL PROTECTED] wrote:
[CCed to debian-devel, since people there are probably interested.]
I'm not sure that's wise, but I've left the cc in place for this
message.
Brian May writes:
BM I am not sure why you would want to say that something depends on
BM an
Brederlow writes:
B It's not quite a port, it's a different operating system. :)
Is a system that uses vim instead of elvis a new port or a new
operating system? My answer is neither, it's just an additional
option for basically the same operating system.
Seriously, though... GNU/Hurd is
On Thu, Apr 01, 1999 at 10:31:29AM +0200, Brederlow wrote:
I would feel disappointed by such a solution. Seperating out a port will
make all integration efforts harder, and please consider the consequences
for our complete infrastructure (mirror, documentation, etc). Furthermore,
most of
Marcus Brinkmann [EMAIL PROTECTED] writes:
On Tue, Mar 30, 1999 at 04:29:36PM +0200, Brederlow wrote:
Furthermore, the Hurd does quite some things differently then linux, and we
will exploit additional functionality beyond the usual Unix system. So,
special versions of tar etc will be used on
Brian May [EMAIL PROTECTED] writes:
However, everything here assumes that only one OS will be used.
Support is required for another field, system, eg
system = {all,linux,hurd,etc}
In sid this is already done this way:
/debian/dists/dist/section/type-system-arch/subsection/
This
On Tue, Mar 30, 1999 at 04:29:36PM +0200, Brederlow wrote:
Wasn't debian-hurd supposed to become compatible with normal linux
binaries, so that no recompilation has to take place? That way
system would not be needed.
Yes, there will be a certain degree of compatibility, even binary
Marcus Brinkmann writes:
Yes, there will be a certain degree of compatibility, even binary
compatibility. But, and this is a big but, we still need our own kernel,
translators, glibc, and some other low level stuff (network, etc).
Just to complicate things: we really should make it possible
Kristoffer Rose writes:
KR Marcus Brinkmann writes:
Yes, there will be a certain degree of compatibility, even binary
compatibility. But, and this is a big but, we still need our own
kernel, translators, glibc, and some other low level stuff
(network, etc).
KR Just to complicate
Julian Gilbey [EMAIL PROTECTED] writes:
I would suggest actually having both in the .changes file, then
dinstall could decide whether to close bugs or change their severity
to fixed based on the content of the two fields. I have handwritten
patches to dinstall and the dpkg-dev scripts
Wichert Akkerman writes (Re: smarter way to differ architectures needed?):
Previously Ian Jackson wrote:
No, it shouldn't. There should possibly be a new field, but
Maintainer is for the maintainer.
A Compiled-by: field would be useful. You can also use that to track
down who
On Fri, Mar 12, 1999 at 12:15:55AM +0100, Wichert Akkerman wrote:
Previously Ian Jackson wrote:
OK, how about this: we rename (in a phased manner) Maintainer (in
.changes) to Uploader.
I definitely agree with this.
Also, we arrange for this new field to appear in the package control
What's then the difference in semantics of Maintainer: and Uploader:
in the .changes? Maintainer: always the source maintainer, and
Uploader: is different only for NMUs?
NMU's and recompiles for other architectures.
Ok...
Roman
Julian Gilbey [EMAIL PROTECTED] writes:
I would suggest actually having both in the .changes file, then
dinstall could decide whether to close bugs or change their severity
to fixed based on the content of the two fields. I have handwritten
patches to dinstall and the dpkg-dev scripts to
Eeks, no! I don't want the Maintainer: field to change on every NMU
-- that would be ghastly, especially if people think to use dpkg -s
to get in contact with the maintainer.
I was talking about Maintainer: in the .changes, not in the package
itself.
Roman
1) add a Compiled-By field to the control-file
Aehm, to debian/control?? That doesn't make sense. debian/control
contains static infos, whereas who compiled a pkg is dynamic.
Oh, I see, you probably mean the control file of packages. Then we
have the following problem: The name of the builder
Previously Roman Hodek wrote:
Oh, I see, you probably mean the control file of packages. Then we
have the following problem: The name of the builder is available only
in dpkg-buildpackage and passed to dpkg-genchanges. dpkg-gencontrol
never sees it... expect we make some tricks with
Wichert Akkerman writes (Re: smarter way to differ architectures needed?):
Previously Ian Jackson wrote:
No, it shouldn't. There should possibly be a new field, but
Maintainer is for the maintainer.
A Compiled-by: field would be useful. You can also use that to track
down who compiled
Previously Ian Jackson wrote:
OK, how about this: we rename (in a phased manner) Maintainer (in
.changes) to Uploader.
I definitely agree with this.
Also, we arrange for this new field to appear in the package control
file, if it is different from Maintainer.
We risk another non-obvious
Previously Ian Jackson wrote:
No, it shouldn't. There should possibly be a new field, but
Maintainer is for the maintainer.
A Compiled-by: field would be useful. You can also use that to track
down who compiled the package for another architecture. I also still
think the Maintainer: entry in a
Previously Ian Jackson wrote:
No, it shouldn't. There should possibly be a new field, but
Maintainer is for the maintainer.
A Compiled-by: field would be useful. You can also use that to track
down who compiled the package for another architecture. I also still
think the Maintainer:
Ian Jackson wrote:
I don't know what to do about this though. Perhaps there needs to be a
way to put the porters email address in bug reports by bug, so that the
maintainer can contact the porter if required.
Perhaps bug should put in an Architecture: pseudo-header ?
Maybe - however, would
Julian Gilbey wrote:
Previously Ian Jackson wrote:
No, it shouldn't. There should possibly be a new field, but
Maintainer is for the maintainer.
A Compiled-by: field would be useful. You can also use that to track
down who compiled the package for another architecture. I also still
A Compiled-by: field would be useful.
Yes (no matter what the exact name is...)
I also still think the Maintainer: entry in a .changes file should
be renamed..
If we have a Compiled-By: field, then Maintainer: can change its
semantics so that it needs no renaming anymore...
What about
Is there a mistake in the Debian Developer's Reference I must
admit, I find it surprising, a new field would be better. Here is an
extract:
[...]
I haven't tested it, but I presume that the -m option overrides
the value for Maintainer, but the documentation is a bit unclear
on this.
Previously Roman Hodek wrote:
But there's still one drawback: The Compiled-By: field is only in the
.changes file and not in the package files :-( Ok, we still can track
down who uploaded what (via Guy's archive of .changes on master), but
the user can't easily do that.
It would probably be
What about these definitions:
Maintainer:
Person responsible for the source version from which this binary
version was built.
In case the upload includes source, must be equal to Compiled-By:.
The value is taken from the latest changelog entry (just like
it's already
In article [EMAIL PROTECTED] you write:
Yes, but there is no way around it until we have better support in some
places like BTS for different packages with same name (the source package
name mustbe different, for sure).
I think another limitation with the current BTS system is the assumption
that
Brian May writes (Re: smarter way to differ architectures needed?):
I think another limitation with the current BTS system is the assumption
that all bugs reports should go to the original maintainer - if the bug
is because of a port to another system and/or architecture, I doubt
the original
IMHO:
A clean solution is required; one which Debian will not regret in the
future.
This is how I interpret what I know about the situation; please
feel free to correct any mistakes... ;-)
FTP LAYOUT
---
Looking at the problem from a different perspective to Marcus; the
ftp layout.
On Fri, Mar 05, 1999 at 05:57:40PM +1100, Brian May wrote:
If the value of system doesn't exist, just assume any (for
arch=any) or all (for arch=all) or linux(???) depending
on the value of arch. I suggest adding a warning if the
arch is hardcoded without and system specified, as it
is not
On Tue, Feb 09, 1999 at 09:09:43PM +0100, Wichert Akkerman wrote:
Previously Guy Maor wrote:
b looks like a reasonable solution, and would not be hard to
implement. Of course, as you said, if only a handful of packages are
affected, then it's less work to do c.
Of course if we reed the
Marcus Brinkmann [EMAIL PROTECTED] writes:
Can you estimate the time you need to prepare this? Can I start to work out
the details for a policy proposal?
First estimate how many packages are involved. If it's only a
handful, it's not worth it (yet).
Guy
On Tue, Feb 09, 1999 at 03:54:42AM -0800, Guy Maor wrote:
b looks like a reasonable solution, and would not be hard to
implement. Of course, as you said, if only a handful of packages are
affected, then it's less work to do c.
(b was about a System: field along to Architecture:)
Can you
[EMAIL PROTECTED] (Marcus Brinkmann) wrote on 09.02.99 in [EMAIL PROTECTED]:
QUESTION: Can one port have a package with the same name as a package in
binary-all? What would happen if I would upload a package makedev with
Architecture: hurd-i386? Would it replace only the symlnk in
On Tue, Feb 09, 1999 at 11:35:23AM +0100, Marco d'Itri wrote:
On Feb 09, Shaleh [EMAIL PROTECTED] wrote:
Seems like a good idea. Maybe we can even get a Debian BSD someday (= The
BSD's could use a nice packager like dpkg.
AFAIK the do not want to use it because it is GPLed.
That's cool.
On 09-Feb-99 Marco d'Itri wrote:
On Feb 09, Shaleh [EMAIL PROTECTED] wrote:
Seems like a good idea. Maybe we can even get a Debian BSD someday (= The
BSD's could use a nice packager like dpkg.
AFAIK the do not want to use it because it is GPLed.
They happily use gcc and friends (=
Hi,
another Hurd thing is (very slowly) approaching, which will become
important for auto building.
Current situation
==
Architecture: all
means that the same package works on all ports.
Architecture: any
means that the package works on all ports, but must be recompiled.
Seems like a good idea. Maybe we can even get a Debian BSD someday (= The
BSD's could use a nice packager like dpkg.
Marcus Brinkmann writes:
MB Hi, another Hurd thing is (very slowly) approaching, which will
MB become important for auto building.
[...]
I have one vague idea that might be a good solution to this problem:
Why not implement the Architecture field using `Depends' (if it isn't
done this way
On Mon, Feb 08, 1999 at 09:52:19PM -0500, Shaleh wrote:
Seems like a good idea. Maybe we can even get a Debian BSD someday (= The
BSD's could use a nice packager like dpkg.
I'd be interested in helping such a port actually.
--
Anticipation is the sweetest form of torture...
Seems like a good idea. Maybe we can even get a Debian BSD someday (= The
In fact, I'm hoping to build a Debian port on top of NetBSD for the
Sun 3, once I get some new disk drives in (and some spare time :-) The
linux sun3 kernel port *is* making progress, so I might end up using
it instead,
b looks like a reasonable solution, and would not be hard to
implement. Of course, as you said, if only a handful of packages are
affected, then it's less work to do c.
Guy
On Feb 09, Shaleh [EMAIL PROTECTED] wrote:
Seems like a good idea. Maybe we can even get a Debian BSD someday (= The
BSD's could use a nice packager like dpkg.
AFAIK the do not want to use it because it is GPLed.
--
ciao,
Marco
Previously Guy Maor wrote:
b looks like a reasonable solution, and would not be hard to
implement. Of course, as you said, if only a handful of packages are
affected, then it's less work to do c.
Of course if we reed the Debian lessions (liw posted a URL for that
recently) we know we have to
75 matches
Mail list logo
