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

Re: How to get d-i udeb packages for hppa-only back into unstable?

John Paul Adrian Glaubitz dixit:

>On 05/02/2014 10:05 PM, Helge Deller wrote:
>>> This needs to be addressed on d-i side; we need better support
>>> for the dpo 'unreleased' suite there.
>> Sounds not very simple or clean.
>> How did you solved that on m68k then?

Not yet. I’m not a big friend of d-i myself (but recognise its
need, of course), so I’ve not done any work in that area. Some
debootstrap patches exist, and IIRC Wouter has done/planned
something on the d-i side, but he also stopped due to lack of

>We didn't yet :(. You have to partition the disk manually and copy
>a root filesystem onto it.

Either that or debootstrap, yes.

>I agree with Thorsten, this is a fundamental problem with Debian ports
>that needs to be addressed, especially when you look at the stats how


>Maybe this problem gets more attention within the rest of Debian when
>sparc, which has recently been dropped from testing, will move to the
>ports side. Since there are still many people running Debian on sparc,
>there might be an incentive to solve this problem.

Absolutely no: everyone who was using sparc post-etch will just change
to sparc64, and people using a real sparc (as opposed to sparc64) have…
other venues… open to them which are OT on this list ;-)

>>The only simple way I see is then to set up an own repository (cloned
>>from debian-ports), add the packages there and then instruct the
>>installer to load the installation packages from there. This is at
>>least how I got it to work sucessfully once.

No, you don't need that. You can work with unstable+unreleased, if you
just tell it to merge the Packages lists in the proper place, and if
the mirror carries both.

That being said: it is not, generally, possible to install (using
either debootstrap or d-i) from “unstable”, even in Debian proper,
due to missing dependencies, library transitions, etc. (which the
dpo-minidak bug that doesn’t keep libraries around for as long as
they’re used makes only worse).

We need some sort of “testing”-lookalike suite, and a way for
ports to opt-in to have packages from “unreleased” migrate into
it. (This is for ports staying on dpo. Ports bootstrapping on
dpo and intending to get into the main archive from there will,
of course, need to have zero packages in “unreleased”, and as
such, their “testing”-alike (I’d call it a different name though,
and ideally one per arch¹) would have only packages from unstable

① if for no other reason that, even when taking only from unstable,
  (binary) package version will differ, adding the need to track
  different versions of source packages too

16:47⎜«mika:#grml» .oO(mira ist einfach gut....)      23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)    23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren	-- Michael Prokop über MirOS bsd4grml

Reply to: