The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Porting sources (was: archive maintainance)



Thanks for your process summary, Juergen, it sounds like exactly what I'd do.
I think it's good to get it recorded in the mailing list archives...

> ok, so i take emacs-19.30-1, change it to build a binary
> (with version number 19.30-1) and file the diffs as bug-report.
> eventually the source maintainer will release a 19.30-2
> version, which will have included the port. in that case
> i simply need to run "./debian.rules binary" in the new
> source to create a 19.30-2 binary package.
> 
> any comments?

I think the only remaining procedural question relates to the fact that your
emacs-19.30-1.deb file would then not be immediately rebuildable from the 
sources that would be in the archive for emacs-19.30-1 as provided by the Intel
platform maintainer (which, of course, assumes that the package starts on 
Intel and goes elsewhere, which is a platform-centric viewpoint, but probably
realistic in this case).  Frankly, I don't consider this a big problem, since
as you indicate the diffs would be filed against the source package in the
defect tracking system, and so anyone who wanted to rebuild the m68k version
from source could find all the required info if they went looking for it.  The
only real alternative would be to have per-architecture source trees, which I
hope we all agree is a *horrid* idea.

A philosophically better situation would be for the source diffs to get back
to the Intel platform maintainer, and for all source and binary packages to
be uploaded in sync as -2 versions... but I sure wouldn't mandate that, as
there is likely to be some syncronization and upstream maintainer reaction
time involved, and it's important in my mind to not delay the availability
of ports to other platforms unduly over purely philosophical issues!

> ps: nevertheless some problems will remain for packages like
> syslinux (i386 boot loader?) or lilo

I see no reason that they couldn't even be handled, if they really are 
completely different for different platforms, as different packages, some of
which are essential for one platform, some of which are essential for another
platform.  Sounds like a small set of corner cases that don't need a lot of
procedural wrangling, to me.

Bdale