Re: Debian-Alpha port ideas...please read (long)
On Fri, 31 Oct 1997, Nikita Schmidt wrote:
> I would rather prefer having those packages fixed. I agree that
> dselectability is an important thing, and yet I feel a bit uncomfortable
> with stubs and anachronisms like ldso. --force-depends is my friend.
I know the feeling, but --force-depends should be used less than we have
had to :) I do agree about stubs in final production stuff, but for now,
it may not be a bad idea until we get more of the "g" libs compiled.
> -dev packages are usually produced from the same source package, so they
> all get fixed together in one shot.
Not necessarily. -dev packages are often hard-coded with dependencies
and, while the libraries that they directly support are depended upon
correctly, they often toss in "libc6" and such that need to be compensated
for.
> It's not evil at all. It is just slightly unaesthetical. (In my
> opinion, at least.)
I agree partially, but necessity is making me lean the other way for at
least awhile. As I like to say, I'll dance with the devil as long as I
don't have to go home with him :P In other words, I don't want that type
of solution to go all the way out to production, but it's a viable
stop-gap solution to an ugly problem.
> That's true: platform specific things should be done by porters.
> Moreover, I don't think that if there was a non-i386 machine where i386
> maintainers could play with getting their packages compiled, that this
> machine would be overpopulated. I don't see any fun in having to go
> through a number of machines whenever I release a new version of my
> package, invoking debian/rules binary on each platform and observing
> various weird errors.
No, but I think if a few of the "bigger" maintainers got a sample of what
we go through here (and the Sparcs too, I'd imagine), then they would
probably have fixed this problem long ago. Also, I agree with your
statement about how many maintainers probably wouldn't even bother trying
another architecture for many reasons, not the least of which is probably
laziness (I know it would be for me -- why should I try there if it works
fine for me here and I don't ever plan on using the other archs? more
work for me if I do). But that's neither here nor there. I guess the
point is that this kinda thing really falls on our shoulders since we're
the ones that are the "porters".
> I think, maintainer-initiated binary uploads should ideally go away.
> Binaries (including i386) should be built automatically (there was some
> talk on debian-devel a while ago on this topic). But that's another
> story.
Yep and I totally agree with automatic package generation. Ideally, it's
a great concept, but it'll never ever fly the way things are currently
handled in about 40% of the packages' debian/rules files.
> I don't see any problems if we change debian/rules to accommodate for
> our platform and send the patch to the original maintainer. After this
> has happened once, the original maintainer will hopefully respect those
> changes while preparing new versions of the package. The only problem
> is that it's an awful lot of work. However, it is much more efficient
> when done centralised rather than left up to the primary maintainers.
> Things of global importance, like, say, a kind request to keep libc5 and
> libc6 specific things separate, can find their way into the policy.
I agree. If we could come up with a pretty general concept and at least
one implementation of the concept to use as an example, then I think it
could become policy to make debian/rules files more "portable". The use
of a configure-like script may basically be in order and may be even what
debian/rules should act like to begin with. That's the kind of thing that
I was thinking should be happening: autodetection of platform (easy),
detection of compat libs and tools (should be easy), and building the
packages based on the previous two steps' results. That way, if we
happened to have libc5 on a PPC, for example, and not libc6, then
not only are the appropriate directives given to the makefile and compiler
by the rules file, but it would also be able to generate a properly named
libfoo package and not even think about trying to make a libfoog package.
Same goes for pure libc6 systems...only libfoog would be produced. On
"cross"-compat systems, both would be built IF the tools to build both
were available (altdev-gcc, etc).
Chris
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: