Re: Debian-Alpha port ideas...please read (long)
On Thursday, 30 Oct, Christopher C Chimelis wrote:
[ about ldso ]
>
> Technically and from my understanding, no we don't. Problem is, existing
> dependencies. We could either create a stub (there's one now, but it
> needs to be updated...should we create one that's versioned like
> 9999.999-99999?) or just hand-axe the dependencies as we see them. Not
> many packages depend on it, but they are out there...
>
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.
>
> Well, as far as actually patching the lib packages in question, you're
> right about this. However, if this is the approach we agree to, I'd
> much rather patch one lib package than have to fix about 10 secondary
> pacakges that are generated with fixed dependencies (yes, they're still
> out there in numbers despite all conventions....-dev packages are prime
> examples).
-dev packages are usually produced from the same source package, so they
all get fixed together in one shot.
>
> > - with "Provides:", for each "g" package there will be one ghost
> > package sitting in the packages database until the transition is
> > over.
>
> I don't think this is so evil, but that's just my opinion.
It's not evil at all. It is just slightly unaesthetical. (In my
opinion, at least.)
>
> Agreed about the Provides option being temporary only and that it should
> go away. As far as the debian/rules problems, I think they'll go away as
> soon as most of the maintainers start messing with getting their stuff
> compiled on other architectures. Honestly, right now, we're doing their
> dirty work for them since we want usable and stable systems. But,
> speaking for myself, I only have so much time and honestly don't feel like
> trying to suggest to the x86 maintainers how things should be done to make
> my platform compilation happy.
>
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.
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.
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.
Nikita
--
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: