Re: smarter way to differ architectures needed?
Brian May <bam@snoopy.apana.org.au> 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 home by downloading at university. Thats pretty common. :)
> >The latest roadblock to my goal is the dpkg notion of Architecture.
> >When that is fixed, we can move on to bigger things, like getting
> >better glibc-2.1 ABI compatibility.
> >
> > B> /debian/link-farm/debian-hurd/... (just hurd stuff below this)
> > B> /debian/link-farm/arch-i386/... (all i386 and all stuff below
> > B> this) /debian/link-farm/slink/... (all slink stuff below here)
> >
> >Okay, now I'm understanding what you mean. Just ignore my above
> >comments if you agree with them... I just want to make things more
> >explicit.
>
> I personally think that we should be using symlinks less and instead
> rely on programs like apt to automagically work out where each file is
> kept. Please read my previous post. This isn't a big issue for me
> though how we arrange the archive, but I don't think major changes
> are required.
Some better method of sorting is required for stuff like apt, the
current structure has been kept to loose and stuff isn`t where one
would expect it (since everyone expect something else). Libs are in
base, but the source in libs. graphics stuff is in x11 and x11 progs
in graphics. libs are in graphics and so on.
The current structure doesn`t cut it.
I think much more structures should be present on the ftp servers via
symlinc farms. I personally would like a big directory with all files
in it, so I can quickly check for new versions via a bash script. Also
a alphabetically sorted tree would be nice to search for a specific
package.
Many people will have many wishes as to how the structure should look
like and most should be fullfiled.
> BTW: Why isn't there the word "slink" embedded in all of the above
> paths? Is that a mistake?
Nope its not. The slink part could be at any position in the tree,
even down to the package level, e.g.:
/debian/link-farm/arch-i386/main/x11/xserver-svga16/slink/xserver-svga16...deb
/debian/link-farm/arch-i386/main/x11/xserver-svga16/potato/xserver-svga16...deb
Or other orders and namings.
...
> 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 everything required the existing mechanism.
> Depends is designed to depend on other packages, it was never meant
> to indicate kernel,arch combination is required to install a package.
Think about em86 for alpha. If a package providing em86 is installed
i386 binaries can be run on an alpha system. In that sense a em86
package would provide arch-i386 for an arch-alpha system.
Some mechanism is needed to make packages invisible when its
dependencies are not met. One doesn`t want to see all i386 packages
along with the alpha packages just because emulation is possible, just
in case emulation is installed those should be shown.
Same for hurd or any other architecture stuff. Architecture packages
must have some flag telling dpkg or dselect or apt that any package
depending on it will not show unless its installed.
> Using Depends line instead of architecture only complicates the matter
> of sorting packages into the Debian archive...
>
> Also: consider for instance compiling a typical binary package that will
> run on any Linux platform.
>
> Currently:
> The source package has
> Architecture: any
That would read:
Depends: arch-any
> This is replace when the package is compiled, eg
> Architecture: i386
and would be replaced
Depends: arch-i386
> I can't see how your method would work. What if the resultant deb file
> will work on any i386 or if another deb file will work on any Hurd
> system (but nothing else)? How would you specify this in the source?
> How would the dpkg packager know to automatically insert the build
> architecture into the depends line? I would rather not have the packager
> do any fooling around with the depends line, except where it is required
> (eg shared libraries).
Its just a matter of renaming the Architecture to Depends.
Also for source the Architecture could remain and the build script
translate that to the right depends lines, also I wouldn`t like that.
> My proposal:
> The source package has:
> Architecture: any-any
> This is replaced when the package is compiled, eg
> Architecture: linux-any
>
> Also: remember that if a package is kernel specific, it doesn't imply
> it is arch specific, and if it is arch specific, it doesn't imply that
> it is kernel specific. In addition, some packages are arch specific in
> that they can never be expected to run on a different {kernel,arch}
> combination, wheres others just need to be recompiled for that kernel
> and/or arch. These are issues that I addressed I have addressed.
Thats the reason why "linux-any", "hurd-any", "any-i386", ... would be
needed.
Whatever you write at the architecture field, call that a package and
write a depends line.
> >That's not a big problem now, but it will get more and more
> >frustrating as we get more compatible (i.e. hurd-libc6 doesn't exist
> >yet, but hurd-libc0.2 still has a lot in common with linux-libc6), and
> >want to duplicate less work.
>
> Eventually, I think it should be possible for the Hurd to share the
> same glibc source package as Linux, however, somebody else will be have
> to verify this. Hence it may be a bad idea to rely on glibc6 having a
> different name on each kernel.
I don`t think so. Multithreading should be way different on hurd than
it is on linux for one thing.
May the Source be with you.
Goswin
Reply to: