Bug#274747: dependency on dpkg-dev is not required for provides

[Josh Triplett-9]

Package: type-handling
Version: 0.2.23
Severity: normal

This issue has just become somewhat more commonplace:
gnome-desktop-environment now uses type-handling, depending on
"gnome-mount | linux-gnu", and on "policykit-1-gnome | not+linux-gnu".
Note that gnome-desktop-environment, as a metapackage, uses
"Architecture: all".  This seems like a very useful application of
type-handling.

Please, consider splitting the provides into a separate package which
does not depend on dpkg-dev.

Thanks,
Josh Triplett

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages type-handling depends on:
ii  dpkg-dev                      1.15.4     Debian package development tools

type-handling recommends no packages.

type-handling suggests no packages.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Sat, Oct 10, 2009 at 08:43:16PM -0700, Josh Triplett wrote:

> Package: type-handling
> Version: 0.2.23
> Severity: normal
>
> This issue has just become somewhat more commonplace:
> gnome-desktop-environment now uses type-handling, depending on
> "gnome-mount | linux-gnu", and on "policykit-1-gnome | not+linux-gnu".
> Note that gnome-desktop-environment, as a metapackage, uses
> "Architecture: all".  This seems like a very useful application of
> type-handling.
>
> Please, consider splitting the provides into a separate package which
> does not depend on dpkg-dev.
>

type-handling has always been a hack to workaround missing features of
dpkg-dev, and it should disappear asap.

dpkg has already support for architecture aliases for a few years, as
far as I remember it can't be used due to missing support on the
build daemons.

Could the dpkg team (Cc:ed) can give us a more detailed status of this
feature, so that we can push it for Squeeze?

Aurelien

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Guillem Jover]

Hi!

On Mon, 2009-10-12 at 10:54:07 +0200, Aurelien Jarno wrote:

> On Sat, Oct 10, 2009 at 08:43:16PM -0700, Josh Triplett wrote:
> > Package: type-handling
> > Version: 0.2.23
> > Severity: normal
> >
> > This issue has just become somewhat more commonplace:
> > gnome-desktop-environment now uses type-handling, depending on
> > "gnome-mount | linux-gnu", and on "policykit-1-gnome | not+linux-gnu".
> > Note that gnome-desktop-environment, as a metapackage, uses
> > "Architecture: all".  This seems like a very useful application of
> > type-handling.
> >
> > Please, consider splitting the provides into a separate package which
> > does not depend on dpkg-dev.
>
> type-handling has always been a hack to workaround missing features of
> dpkg-dev, and it should disappear asap.
>
> dpkg has already support for architecture aliases for a few years, as
> far as I remember it can't be used due to missing support on the
> build daemons.
>
> Could the dpkg team (Cc:ed) can give us a more detailed status of this
> feature, so that we can push it for Squeeze?

That only works for arch:any packages, here the problem is related to
an arch:all package. The wildcards on arch:any packages should be
mostly usable, last time I checked it was pending for all buildd to
be switched to the new sbuild (which has such support).

Adding wildcard support to arch:all packages would imply a wait time
of one release before being usable, as the syntax of the dependncy
fields would change.

Another possibility is to switch the package to an arch:any one. It's
a metapackages anyway so it does not take much space on the servers. And
actually an argument could be made that an arch:all package which
requires different dependencies on different architectures is not a
trully arch:all package.

regards,
guillem



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Mon, Oct 12, 2009 at 01:05:18PM +0200, Guillem Jover wrote:

> Hi!
>
> On Mon, 2009-10-12 at 10:54:07 +0200, Aurelien Jarno wrote:
> > On Sat, Oct 10, 2009 at 08:43:16PM -0700, Josh Triplett wrote:
> > > Package: type-handling
> > > Version: 0.2.23
> > > Severity: normal
> > >
> > > This issue has just become somewhat more commonplace:
> > > gnome-desktop-environment now uses type-handling, depending on
> > > "gnome-mount | linux-gnu", and on "policykit-1-gnome | not+linux-gnu".
> > > Note that gnome-desktop-environment, as a metapackage, uses
> > > "Architecture: all".  This seems like a very useful application of
> > > type-handling.
> > >
> > > Please, consider splitting the provides into a separate package which
> > > does not depend on dpkg-dev.
> >
> > type-handling has always been a hack to workaround missing features of
> > dpkg-dev, and it should disappear asap.
> >
> > dpkg has already support for architecture aliases for a few years, as
> > far as I remember it can't be used due to missing support on the
> > build daemons.
> >
> > Could the dpkg team (Cc:ed) can give us a more detailed status of this
> > feature, so that we can push it for Squeeze?
>
> That only works for arch:any packages, here the problem is related to
> an arch:all package. The wildcards on arch:any packages should be
> mostly usable, last time I checked it was pending for all buildd to
> be switched to the new sbuild (which has such support).
>
> Adding wildcard support to arch:all packages would imply a wait time
> of one release before being usable, as the syntax of the dependncy
> fields would change.
>
> Another possibility is to switch the package to an arch:any one. It's
> a metapackages anyway so it does not take much space on the servers. And
> actually an argument could be made that an arch:all package which
> requires different dependencies on different architectures is not a
> trully arch:all package.
>

Another option is that all the Provides: part of type-handling is done
on dpkg. The current problem with the implementation:
- A rebuild of type-handling is needed each time a new architecture is
  added to dpkg.
- Provides do not always work as an alternative. This require for
  example type-handling to be installed on the build daemons
  (technically it should be an Essential package for this to work).

That's why I am not really for more usage of type-handling, which IMHO
should simply disappear.

--
Aurelien Jarno                        GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Aurelien Jarno <aurelien@...> writes:

> On Mon, Oct 12, 2009 at 01:05:18PM +0200, Guillem Jover wrote:
> Another option is that all the Provides: part of type-handling is done
> on dpkg. The current problem with the implementation:
> - A rebuild of type-handling is needed each time a new architecture is
>   added to dpkg.
> - Provides do not always work as an alternative. This require for
>   example type-handling to be installed on the build daemons
>   (technically it should be an Essential package for this to work).
>
> That's why I am not really for more usage of type-handling, which IMHO
> should simply disappear.

This gets even worse with multiarch.

Depending on the dpkg config (what archs to allow, and any multiarch
config will break something) the type-handling will break down.

Examples:

amd64 + i386: amd64 has not-i386 and i386 has not-amd64. It is kind of
strange that you are both i386 and not-i386 but that is multiarch for
you.

amd64 + kfreebsd-amd64: Now you have linux and not-linux.

I already saw some nice confusing effects of this with ia32-apt-get
and had to blacklist type-handling from the non-native archs.

MfG
        Goswin



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...