Your message dated Sun, 21 Feb 2016 09:38:49 +0100
with message-id <[email protected]>
and subject line Re: Bug#796236: dpkg-dev: Please add support for bits in arch
wildcards
has caused the Debian Bug report #796236,
regarding dpkg-dev: Please add support for bits in arch wildcards
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
796236: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796236
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Severity: wishlist
Version: 1.18.2
Hi,
we just had the 32bit arches in debian-bof, and two changes to dpkg
would help us:
1. Architectures linux-any-32 and linux-any-64 for the 32 and 64 bit
architectures respectivly.
2. The possibility to exclude architectures, e.g. to write "any !i386"
instead of listing all other architectures explicitly.
It would be helpful if these two changes could be make to the relevant
dpkg parts.
Thanks!
Andi
--- End Message ---
--- Begin Message ---
Control: tags -1 moreinfo wontfix
Hi!
On Thu, 2015-09-10 at 14:37:46 +0200, Guillem Jover wrote:
> On Thu, 2015-08-20 at 15:18:30 +0200, Andreas Barth wrote:
> > Package: dpkg
> > Severity: wishlist
> > Version: 1.18.2
>
> > we just had the 32bit arches in debian-bof, and two changes to dpkg
> > would help us:
> >
> > 1. Architectures linux-any-32 and linux-any-64 for the 32 and 64 bit
> > architectures respectivly.
>
> This would be a mess to deploy, would break the current convention of
> naming the triplets, and would make the already confusing wildcards
> even more confusing. Developers having to deal with such wildcards
> outside of dpkg, are already complaining that they cannot do simple
> string matches, embedding the bits there implies they are forced to
> parse the string, have to distinguish those from actual valid triplet
> components, and then parse and apply the information from the dpkg
> architecture table files.
>
>
> <https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_a_new_dpkg_architecture.3F>
> <https://wiki.debian.org/Teams/Dpkg/TimeTravelFixes>
>
> Where would you need such wildcards, I'm assuming on very few very low
> level packages, such as boot loaders and similar?
>
> In any case, I can see that when this is needed, it would be way more
> convenient to use a bits-based wildcard, because it's more future
> proof, and should in principle be always up-to-date. OTOH, if this is
> for such low-level packages, then usually it requires explicit support
> for every and each port, so you have to track that manually most of
> the time anyway, and using such wildcards might be wrong.
Given no further replies, and the concerns above, I'm going ahead and
closing this. If more information comes along (preferably a convincing
and strong argument), feel free to reopen.
Thanks,
Guillem
--- End Message ---
