FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-15-2011, 06:06 AM
Raphael Hertzog
 
Default Upcoming FTPMaster meeting

On Mon, 14 Feb 2011, Philipp Kern wrote:
> You'd lose the notion of it being useful on other architectures (that's the
> arch:all -> arch:i386 Raphael's talking about), though. But then packages
> like qemu-system would just depend on openbios-sparc:sparc, no? If you
> don't need to deal with them directly that'd be pretty transparent.

The current Multi-Arch spec doesn't allow for such explicit dependencies
(targeting a precise foreign architecture).

But you can have "openbios-sparc:any" and assuming openbios-sparc is only
available on sparc, the right package would be picked.

See http://wiki.ubuntu.com/MultiarchSpec

> But then so far multiarch didn't happen... ):

But it's really not far away this time.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110215070642.GD32427@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110215070642.GD32427@rivendell.home.ouaza.com
 
Old 02-15-2011, 06:30 AM
Philipp Kern
 
Default Upcoming FTPMaster meeting

On 2011-02-15, Steve Langasek <vorlon@debian.org> wrote:
> I wasn't suggesting the use of -backports here, I was referring to
> backported features in the general sense of the term.

I know. -backports would've been the "easy" way out, though. But obviously a
no-go for official infrastructure.

> Of course I'm not taking it for granted that you would accept these packages
> into squeeze and intended to ask you if this would be ok, once there were
> actual patches to be considered. But since you're here: would targeted
> patches to backport support for :any/:native be ok for a stable update? :-)

Is this just about parsing/accepting them or also more intrusive dependency
analysis? For basic parsing support that might be ok if the patch is sanely
reviewable and guaranteed not to cause regressions. No guarantees about
acceptable, though.[*]

Most of the support work should happen with the chroot apt and dpkg I guess,
to speed this up.

Kind regards
Philipp Kern
[*] It's also a bit of cheating if we allow such updates into stable.
Why didn't we add other compression formats and other source formats to
dpkg in stable then; we did claim that you need to wait a cycle for them to
be used. I don't want that can of worms to be opened.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnilkasl.2n9.trash@kelgar.0x539.de">http://lists.debian.org/slrnilkasl.2n9.trash@kelgar.0x539.de
 
Old 02-15-2011, 06:53 AM
Guillem Jover
 
Default Upcoming FTPMaster meeting

Hi!

On Mon, 2011-02-14 at 08:39:21 +0100, Raphael Hertzog wrote:
> On Sat, 12 Feb 2011, Guillem Jover wrote:
> > Using Build-Architecture would be a workaround, it should not be
> > needed once multiarch is in place and those packages are built for
> > their respective architectures.
>
> While technically true, this can be discussed. I can imagine that you
> might not want to configure multiarch on your system just because you
> need some bootloaders files (e.g. syslinux-common in a CD build process).
>
> Using multi-arch to solve this problem means changing the package from
> arch: all to arch: i386 (or the specific arch set that you're interested
> in).

Well that's precisely one of the cases multiarch is designed for, so I
don't see why we'd not use it there.


To clarify a bit my remark and complement what Philipp mentioned, there's
mainly two kinds of packages that could require Build-Architecture:

1) Firmware for emulators

Or just code that does not get run by the host, and requires a
cross-compiler if not built on the host. Things like seabios, bochsbios,
openbios, openhackware, proll, but not vgabios (which uses bcc/bin86,
a kind of cross-compiler by design). This would get switched to arch:foo
from arch:all. The packages needing them would pull them. And yes this
requires changing the arch, but it's the correct thing to do (the other
valid option in my mind would be to have cross-compilers available and
keeping them as arch:all, but we don't). This only has the slight
inconvenience that apt would need to pull the Packages files for all
involved architectures, but filtered Packages files could be provided,
as hinted by Steve.

2) Bootloaders

Or just code that gets run by the host, although possibly in another
processor mode. Things like grub, syslinux, etc. This is currently
handled by the bi-arch toolchains, and I'd expect it to continue being
the case for quite a while after multiarch deployment, or at least I
don't see the freestanding bi-arch compiler bits disabled immediately
if at all, or ever?


So the case you mention using a bootloader for a CD is a mix of both
1) and 2), which although keeping syslinux-common as arch:all might
work somehow ok, it'd not be possible for something like grub2 which
can boot from CD too for example, but goes beyond the bi-arch realm.
So the correct eventual solution, seems to me to switch any such
package from arch:all to arch:foo.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110215075330.GA16644@gaara.hadrons.org">http://lists.debian.org/20110215075330.GA16644@gaara.hadrons.org
 
Old 02-15-2011, 07:47 AM
Steve Langasek
 
Default Upcoming FTPMaster meeting

On Tue, Feb 15, 2011 at 08:06:42AM +0100, Raphael Hertzog wrote:
> On Mon, 14 Feb 2011, Philipp Kern wrote:
> > You'd lose the notion of it being useful on other architectures (that's the
> > arch:all -> arch:i386 Raphael's talking about), though. But then packages
> > like qemu-system would just depend on openbios-sparc:sparc, no? If you
> > don't need to deal with them directly that'd be pretty transparent.

> The current Multi-Arch spec doesn't allow for such explicit dependencies
> (targeting a precise foreign architecture).

> But you can have "openbios-sparc:any" and assuming openbios-sparc is only
> available on sparc, the right package would be picked.

Well, the current Multi-Arch spec doesn't allow for it precisely because we
want ports to remain self-hosting in the first round. So if openbios-sparc
is only available as an Architecture: sparc package, a Depends:
openbios-sparc:any is as bad as Depends: openbios-sparc:sparc for ensuring
packages remain installable within a single architecture.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 02-15-2011, 12:42 PM
Roger Leigh
 
Default Upcoming FTPMaster meeting

On Mon, Feb 14, 2011 at 04:28:49PM -0800, Steve Langasek wrote:
> On Mon, Feb 14, 2011 at 09:52:32PM +0000, Roger Leigh wrote:
> > On Mon, Feb 14, 2011 at 01:08:51PM -0800, Steve Langasek wrote:
> > > And although for the most part the roll-out of multiarch is intended to be
> > > backwards-compatible and a smooth transition, there are two small extensions
> > > required to the package relationship fields in order to deploy a full
> > > multiarch stack in the archive. The archive software doesn't need to
> > > *support* these extensions in the context of a self-hosting port, but
> > > anything that parses deps or build-deps (dak?, sbuild, wanna-build) should
> > > recognize these extensions and strip them off:
>
> > > - Depends: foo:any - an extension used to declare that foo of any
> > > architecture satisfies the dependency. The archive and official
> > > autobuilders should treat this as equivalent to 'Depends: foo'.[1]
>
> > sbuild switched to using Dpkg:eps for parsing dependencies; we would
> > ideally want an equivalent to Dpkg:eps::reduce_arch() to do the
> > stripping (if reduce_arch wasn't the appropriate place to do it
> > already). This saves us from reimplementing yet another parser, and
> > it getting outdated; we currently use it for stripping dependencies
> > not needed for the build's architecture.
>
> Does this need to be backported to the squeeze dpkg to be usable on the
> buildds? I assume it will. (I'm making my list of features we're going to
> want backported in apt/dpkg for buildds in relation to this, since we missed
> the boat by a bit for squeeze.)

Well, for Lenny we imported Dpkg:eps into the sbuild.git tree as
Sbuild:eps (currently on the buildd-merge2 branch; it's not in use yet,
and now squeeze is out is redundant). We can always do the same for
Squeeze if backporting dpkg itself is not acceptable. It will be even
easier since now the other libdpkg-perl modules it depends on won't need
importing as well. So we have the option of importing if backporting is
not an option.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 02-15-2011, 01:44 PM
Mark Hymers
 
Default Upcoming FTPMaster meeting

On Mon, 14, Feb, 2011 at 01:08:51PM -0800, Steve Langasek spoke thus..
> I'm happy to file bug reports against the appropriate components if that's
> the right thing to do here; I'm raising it on the list first because I'm not
> sure whether dak is actually affected, and if so whether ftp.debian.org is
> the right place to report the issue.

I've put it on the agenda so we can check if it does affect dak and fix
it if it does.

Cheers,

Mark

--
Mark Hymers <mhy at debian dot org>

"That's why the good die young; it's because Death can't be bothered to check
the paperwork."
Andy Hamilton, Old Harry's Game


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110215144434.GA15868@hymers.org.uk">http://lists.debian.org/20110215144434.GA15868@hymers.org.uk
 
Old 02-15-2011, 03:55 PM
Steve Langasek
 
Default Upcoming FTPMaster meeting

On Tue, Feb 15, 2011 at 07:30:29AM +0000, Philipp Kern wrote:

> > Of course I'm not taking it for granted that you would accept these packages
> > into squeeze and intended to ask you if this would be ok, once there were
> > actual patches to be considered. But since you're here: would targeted
> > patches to backport support for :any/:native be ok for a stable update? :-)

> Is this just about parsing/accepting them or also more intrusive dependency
> analysis? For basic parsing support that might be ok if the patch is sanely
> reviewable and guaranteed not to cause regressions. No guarantees about
> acceptable, though.[*]

Strictly about parsing them.

>[*] It's also a bit of cheating if we allow such updates into stable.
> Why didn't we add other compression formats and other source formats to
> dpkg in stable then; we did claim that you need to wait a cycle for them to
> be used. I don't want that can of worms to be opened.

I see your point. Actually, I was thinking in terms of this being required
only on the buildds; but anyone upgrading from squeeze .0 to wheezy would
also be impacted if they tried to use a dpkg and/or apt that didn't
understand this syntax. We might have no choice but to defer use of :any
until the wheezy release. :/

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 02-15-2011, 04:04 PM
Mark Hymers
 
Default Upcoming FTPMaster meeting

On Tue, 15, Feb, 2011 at 08:55:50AM -0800, Steve Langasek spoke thus..
> >[*] It's also a bit of cheating if we allow such updates into stable.
> > Why didn't we add other compression formats and other source formats to
> > dpkg in stable then; we did claim that you need to wait a cycle for them to
> > be used. I don't want that can of worms to be opened.
>
> I see your point. Actually, I was thinking in terms of this being required
> only on the buildds; but anyone upgrading from squeeze .0 to wheezy would
> also be impacted if they tried to use a dpkg and/or apt that didn't
> understand this syntax. We might have no choice but to defer use of :any
> until the wheezy release. :/

Could we choose to document that it can only be used in wheezy (enforced
by dak if necessary) and above and then have the release notes state
that users must upgrade dpkg and apt to the latest point release before
doing the dist-upgrade?

Mark

--
Mark Hymers <mhy at debian dot org>

"I got off at Durham... and fell in love with it instantly. Why, it's
wonderful - a perfect little city. If you have never been to Durham, go
there at once. Take my car. It's wonderful."
Notes from a Small Island, Bill Bryson


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110215170455.GA22761@hymers.org.uk">http://lists.debian.org/20110215170455.GA22761@hymers.org.uk
 
Old 02-15-2011, 04:40 PM
Olaf van der Spek
 
Default Upcoming FTPMaster meeting

On Tue, Feb 15, 2011 at 6:04 PM, Mark Hymers <mhy@debian.org> wrote:
> Could we choose to document that it can only be used in wheezy (enforced
> by dak if necessary) and above and then have the release notes state
> that users must upgrade dpkg and apt to the latest point release before
> doing the dist-upgrade?

Such things should not be documented. Either it shouldn't be necessary
or it should be done automatically.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTim15VXyKKPC1J2fXTamrTxthWgAbVcTi5GchYHt@mail .gmail.com">http://lists.debian.org/AANLkTim15VXyKKPC1J2fXTamrTxthWgAbVcTi5GchYHt@mail .gmail.com
 

Thread Tools




All times are GMT. The time now is 12:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org