On Sun, Jul 16, 2023 at 7:50 AM Jonas Smedegaard wrote:
> I now recall: The Rust library packages wreaking havoc by prematurely
> entering testing is (at least partly) due to the Rust team choosing to
> flag all(!) autopkgtests as flaky, so not really a concern for other
> teams (read: just don't
uild-Depend: libada-foo-dev
> > binary -dev packages Depend: libada-foo-dev-HASH
> > The intent is similar to the one of shared object versions, but the
> > name changes often (for example, with the architecture) and is
> > computed, so virtual packages seem more a
source packages Build-Depend: libada-foo-dev
> > binary -dev packages Depend: libada-foo-dev-HASH
> > The intent is similar to the one of shared object versions, but the
> > name changes often (for example, with the architecture) and is
> > computed, so virtual packages seem mo
SH
> The intent is similar to the one of shared object versions, but the
> name changes often (for example, with the architecture) and is
> computed, so virtual packages seem more appropriate.
>
> Policy 3.6 does not disapprove:
> ... should not use virtual package names (
the
name changes often (for example, with the architecture) and is
computed, so virtual packages seem more appropriate.
Policy 3.6 does not disapprove:
... should not use virtual package names (except privately,
amongst a cooperating group of packages) unless they have been
agreed upon
On Sat, 29 Jan 2022 at 20:12:21 +, Simon McVittie wrote:
> I propose this entry for virtual-package-names-list.yaml:
>
> - name: wayland-session
> description: a Wayland desktop session
> (/usr/share/wayland-sessions/*.desktop)
Having looked more closely at display managers, I think we sho
Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org, charlesmel...@outlook.com,
on...@debian.org
thanks
I'd like to propose adding the virtual packages "todo" and "todo.txt" to
the authoritative list of virtual package n
Hello,
чт, 1 авг. 2019 г. в 13:18, Fabian Greffrath :
>
> Dear debian-devel,
>
> we, the maintainers of soundfont packages in Debian, i.e. currently
> mostly Thorsten Glaser and myself, would like to propose the
> introduction of two additional virtual packages:
>
>
As a user of soundfonts, this proposal would solve a problem I've run
into. It seems well thought out so I support it.
--Sam
Dear debian-devel,
we, the maintainers of soundfont packages in Debian, i.e. currently
mostly Thorsten Glaser and myself, would like to propose the
introduction of two additional virtual packages:
sf2-soundfont-gm
sf3-soundfont-gm
Background: There is currently no default
it avoids ambiguity if apt
is configured to see more than one suite (perhaps unstable and testing, or
testing and stable-security) and the package providing default-d-s-b differs
between those suites.
If the scheme involving two virtual packages is preferred over this
option, I would very much appreciate
Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org
I propose two new virtual packages:
dbus-session-bus: anything providing the D-Bus well-known session bus
for user login sessions
dbus-default-session-bus: Debian's preferred implementation of
dbus-sessio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/08/14 15:06, Gunnar Wolf wrote:
>> This will enable the alternative MariaDB and Percona packages to
>>> satisfy the dependency. MySQL 5.5, MariaDB 5.5 and PXC 5.5 are
>>> all binary-compatible and most likely to work with any program
>>> that c
James Page dijo [Fri, Aug 01, 2014 at 10:57:44AM +0100]:
> (...)
> The wider intent is that all maintainers of packages that depend on
> mysql-server or mysql-client are encouraged to add as alternative
> dependencies the virtual packages virtual-mysql-server[1] or
> virtual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Fellow Devel's
Over the last 6 months, we have introduced a few new MySQL variants
into Debian and expanded the use of the existing (but never formalized
AFAICT) virtual-mysql-* virtual packages to supporting switching
in/out the diff
Ondřej Surý writes (""security-aware-resolver" virtual package (Was: Two new
DNS virtual packages (authoritative-name-server & recursive-name-server))"):
> since the authoritative-name-server idea was rejected by the list, I was
> going to propose alternative
On 10/24/2013 12:30 AM, Ondřej Surý wrote:
> On Tue, Oct 22, 2013, at 20:16, Octavio Alvarez wrote:
>> On 22/10/13 09:18, Arturo Borrero Gonzalez wrote:
>>> I would suggest: caching-name-server
>>
>> *-dns-server would be better, as it is specific enough to avoid name
>> collision in the future.
>
On Tue, Oct 22, 2013, at 20:16, Octavio Alvarez wrote:
> On 22/10/13 09:18, Arturo Borrero Gonzalez wrote:
> > I would suggest: caching-name-server
>
> *-dns-server would be better, as it is specific enough to avoid name
> collision in the future.
JFTR that should not be any name collisions as t
Hi James,
since the authoritative-name-server idea was rejected by the list, I was
going to propose alternative:
security-aware-resolver
The definition from RFC4033:
Security-Aware Resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [RFC1034]) that understan
As a side note to this discussion, more interesting than a list of
all resolvers would be a list of /verifying/ resolvers.
An easy way to find all packaged verifying resolvers, to choose one
for local installation would help many users.
And an easy way to depend on a local verifier would help bot
Le Tue, Oct 22, 2013 at 03:43:03PM +0200, Ondřej Surý a écrit :
>
> The proposed names are:
>
> authoritative-name-server - authoritative domain name server
> recursive-name-server - recursive domain name server
Dear Ondřej,
I am planning a Policy update by the end of the month.
My understandi
On Tue, Oct 22, 2013 at 9:29 AM, Simon McVittie wrote:
>
> If you depend on one of these, what functionality can you rely on having
> "out of the box"? What packages do you expect to benefit from having
> these virtual packages to depend on?
I'm wondering the same th
On 22 October 2013 20:16, Octavio Alvarez wrote:
> On 22/10/13 09:18, Arturo Borrero Gonzalez wrote:
>>
>> I would suggest: caching-name-server
>
>
> *-dns-server would be better, as it is specific enough to avoid name
> collision in the future.
Good point.
Thanks.
--
Arturo Borrero González
On 22/10/13 09:18, Arturo Borrero Gonzalez wrote:
I would suggest: caching-name-server
*-dns-server would be better, as it is specific enough to avoid name
collision in the future.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Co
On Tue, 22 Oct 2013, Russ Allbery wrote:
> > I would suggest: caching-name-server
>
> That's basically what a recursive-name-server is. I don't think the
> application should care whether it caches locally or not; that's up to the
> local administrator.
Almost every recursive resolver does cachi
Arturo Borrero Gonzalez writes:
> On 22 October 2013 15:43, Ondřej Surý wrote:
>> there are now couple of quality DNS servers and most of their
>> maintainers have agreed that it might be useful to have a virtual
>> package that we can add to Provides: so it's easy to pick one DNS
>> server if o
On Tue, 22 Oct 2013 16:41:30 +0200, Ond?ej Surý
wrote:
>We might discuss whether recursive-name-server or caching-name-server
>would be better match, but I think that not all recursive name server
>has to be caching, but all caching name server has to be recursive. And
>the IETF (at least the DNSS
On 22 October 2013 15:43, Ondřej Surý wrote:
> Hi,
>
> there are now couple of quality DNS servers and most of their
> maintainers have agreed that it might be useful to have a virtual
> package that we can add to Provides: so it's easy to pick one DNS server
> if one needs it.
>
> The proposed na
e server
>>> Any objections?
>> If you depend on one of these, what functionality can you rely on
>> having "out of the box"? What packages do you expect to benefit from
>> having these virtual packages to depend on?
> Break free from the technical aspect of
"Ondřej Surý" wrote:
>Hi,
>
>there are now couple of quality DNS servers and most of their
>maintainers have agreed that it might be useful to have a virtual
>package that we can add to Provides: so it's easy to pick one DNS
>server
>if one needs it.
>
>The proposed names are:
>
>authoritative-n
On Tue, Oct 22, 2013, at 15:52, Jonathan Dowland wrote:
>
> At risk of coming across as a bikeshedder,
>
> On Tue, Oct 22, 2013 at 03:43:03PM +0200, Ondřej Surý wrote:
> > authoritative-name-server - authoritative domain name server
> > recursive-name-server - recursive domain name server
>
> Is
; Any objections?
>
> If you depend on one of these, what functionality can you rely on having
> "out of the box"? What packages do you expect to benefit from having
> these virtual packages to depend on?
Break free from the technical aspect of resolving dependencies. The
vir
ng
"out of the box"? What packages do you expect to benefit from having
these virtual packages to depend on?
For a recursive name server, is the expected functionality "it listens
on port 53, and will resolve DNS names without relying on any non-local,
non-authoritative DNS servers&quo
At risk of coming across as a bikeshedder,
On Tue, Oct 22, 2013 at 03:43:03PM +0200, Ondřej Surý wrote:
> authoritative-name-server - authoritative domain name server
> recursive-name-server - recursive domain name server
Is there a need to distinguish between "name server" and "domain name
serv
Hi,
there are now couple of quality DNS servers and most of their
maintainers have agreed that it might be useful to have a virtual
package that we can add to Provides: so it's easy to pick one DNS server
if one needs it.
The proposed names are:
authoritative-name-server - authoritative domain n
On Thu, Oct 03, 2013 at 01:04:09PM +0200, David Kalnischkies wrote:
> On Thu, Oct 3, 2013 at 11:54 AM, Vincent Danjean wrote:
> > I tried several variation, adding :same and/or :i386/:amd64 to
> > the Conflicts and/or Provides in ICD Loader. I do not succeed into
> :same doesn't exist (in this
ncl1
> Replaces: libopencl1
> Suggests (or Recommends): opencl-icd
That Replaces makes no sense.
Why isn't that a Depends on opencl-icd? I assume a loader is
useless without any implementations being installed, and the
application would just depend on libopencl1 instead of both
vir
Le 03/10/2013 13:04, David Kalnischkies a écrit :
> On Thu, Oct 3, 2013 at 11:54 AM, Vincent Danjean wrote:
>> I tried several variation, adding :same and/or :i386/:amd64 to
>> the Conflicts and/or Provides in ICD Loader. I do not succeed into
>
> :same doesn't exist (in this context), where di
Le 03/10/2013 13:28, Simon McVittie a écrit :
> On 03/10/13 10:54, Vincent Danjean wrote:
>> The only "problem" is that it is not currently possible to install
>> an ICD Loader:i386 from one vendor and an ICD Loader:amd64 from another
>> vendor.
>
> Is there a valid reason to do that, other than
On 03/10/13 10:54, Vincent Danjean wrote:
> The only "problem" is that it is not currently possible to install
> an ICD Loader:i386 from one vendor and an ICD Loader:amd64 from another
> vendor.
Is there a valid reason to do that, other than "because I can"? If
nobody would actually want to do t
On Thu, Oct 3, 2013 at 11:54 AM, Vincent Danjean wrote:
> I tried several variation, adding :same and/or :i386/:amd64 to
> the Conflicts and/or Provides in ICD Loader. I do not succeed into
:same doesn't exist (in this context), where did you find that?
Anyway, negative dependencies (Conflicts/
Hi,
While trying to setup a correct description of dependencies for OpenCL
eco-system, we got a problem related to multi-arch. I will try to describe
here a simplified version of the situation to illustrate our main problem
(ie I do not take into account the various versions of OpenCL that can
On 09/26/2013 01:19 AM, Paul Wise wrote:
Do you also plan to get rid of these? They appear to be designed to
block auto-removal of installed linux-image-* and linux-header-*
packages.
/etc/kernel/postinst.d/apt-auto-removal
/etc/apt/apt.conf.d/01autoremove-kernels
I would hope not. Whereas (f
Do you also plan to get rid of these? They appear to be designed to
block auto-removal of installed linux-image-* and linux-header-*
packages.
/etc/kernel/postinst.d/apt-auto-removal
/etc/apt/apt.conf.d/01autoremove-kernels
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, emai
I'd like to stop the binary packages built from linux providing the
following virtual packages:
* linux-image
As explained in #724569, any relations on a virtual package prevent
auto-removal of all providing packages, so in this case linux-image-*
packages must be manually removed to
Le 21/11/2012 17:48, Ian Jackson a écrit :
>> Although I'd agree that defining a new lv2-plugin would not be needed,
>> making LV2 plugins packages Depend/Recommend a generic lv2-host
>> package would seriously help as it allows maintainers to avoid to fill
>> up Depends: fields with long and incom
On 21 Nov 2012, at 17:27, Russ Allbery wrote:
> don't know if Ian is, but I certainly would. We have a bunch of
> existing virtual packages that aren't really useful because they don't
> offer any sort of guaranteed interface, and therefore cannot be
> meaningfully us
On 21/11/12 17:27, Russ Allbery wrote:
> Without that, it's questionable whether the
> virtual package serves any purpose, and indeed you'll find that the CD
> ripping packages in Debian don't reference mp3-encoder
... and perhaps more tellingly, only one package Provides it, and that
package isn'
Alessio Treglia writes:
> Why tightening up rules? Policy §3.6 does not pretend packages to meet
> any specs nor comply with common interfaces, it just says "Sometimes
> there are several packages which offer more-or-less the same
> functionality. In this case, it's useful to define a virtual pac
Jonas Smedegaard writes:
> It seems to me that you are applying more strict rules now than has been
> applied to other names on the list in the past.
I don't know if Ian is, but I certainly would. We have a bunch of
existing virtual packages that aren't really useful because
Alessio Treglia writes ("Re: New virtual packages: lv2-plugin and lv2-host"):
> On Wed, Nov 21, 2012 at 3:03 PM, Ian Jackson
> wrote:
> > So I'm afraid I still don't understand how this virtual package would
> > help improve the dependency resolution.
>
On Wed, Nov 21, 2012 at 3:03 PM, Ian Jackson
wrote:
> So I'm afraid I still don't understand how this virtual package would
> help improve the dependency resolution.
Although I'd agree that defining a new lv2-plugin would not be needed,
making LV2 plugins packages Depend/Recommend a generic lv2-h
On 21 November 2012 22:51, Alessio Treglia wrote:
> Actually I receive lots of mails from users asking me questions like "How
> could
> I find an exhaustive list of LV2 toys currently provided by Debian?", "Does
> the
> X sequencer support LV2 plugins?". So, I think we'd do a good service to our
vided by Debian?", "Does= the X sequencer support LV2
> plugins?". So, I think we'd do a good service to ou= r users by
> grouping audio hosts and plugins by features they do provide. [1]
Isn't this something which would better be dealt with by debtags ?
The purpose o
lugins by features they do provide. [1]
[1] That does not mean I think it'd be appropriate to populate audio plugins'
Provides: field with long lists of virtual packages. The original proposal
was just about LV2 because of its constantly increasing popularity.
Cheers!
--
A
Jonas Smedegaard writes ("Re: New virtual packages: lv2-plugin and lv2-host"):
> It seems to me that you are applying more strict rules now than has been
> applied to other names on the list in the past.
This is not some kind of hazing ritual where people have to persuade a
re
Quoting Ian Jackson (2012-11-21 13:40:35)
> Alessio Treglia writes ("Re: New virtual packages: lv2-plugin and lv2-host"):
> > On Tue, Nov 20, 2012 at 2:27 PM, Ian Jackson
> > wrote:
> > > And an lv2-host could include something which can use only p
Alessio Treglia writes ("Re: New virtual packages: lv2-plugin and lv2-host"):
> On Tue, Nov 20, 2012 at 2:27 PM, Ian Jackson
> wrote:
> > And an lv2-host could include something which can use only plugins
> > with certain features.
>
> Altough dillo doesn
Hi Ian,
thanks for the quick reply!
On Tue, Nov 20, 2012 at 2:27 PM, Ian Jackson
wrote:
> An lv2-plugin could be almost anything AFAICT, so depending on "some
> LV2 plugin" is not very useful.
>
> And an lv2-host could include something which can use only plugins
> with certain features.
Altoug
Alessio Treglia writes ("New virtual packages: lv2-plugin and lv2-host"):
> virtual-package-list.txt.gz [1] says:
>
>1. Post to debian-devel saying what names you intend to use or what
> other changes you wish to make, and file a wish list bug against the
>
Hi everybody,
virtual-package-list.txt.gz [1] says:
1. Post to debian-devel saying what names you intend to use or what
other changes you wish to make, and file a wish list bug against the
package debian-policy.
So, here is my proposal:
--- debian-policy-3.9.4.0/virtual-package-n
Package: debian-policy
Version: 3.8.4.0
Severity: wishlist
Justification: Policy §3.6
X-Debbugs-CC: debian-devel@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
As of today[1], the Java Policy retired the use of the virtual packages
mentioned
in the subject line, which
Someone wrote:
> If you actually need to make this sort of response, could you do the
> rest of us a favor and not do so publicly?
Ya, you're right. Sorry.
My frustration got the better of me.
- Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Con
On Thu September 27 2007 05:38:53 pm Manoj Srivastava wrote:
> On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
> > The bit you're still missing is the first part of the question you
> > didn't answer: "Is there any situation where ownership has
> > collided"
> >
> > IOW: if
On Thu, 27 Sep 2007 08:08:49 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
> The bit you're still missing is the first part of the question you
> didn't answer: "Is there any situation where ownership has collided"
> IOW: if the file shared by many packages isn't having ownership
> problems there
On Thu September 27 2007 01:33:21 am Manoj Srivastava wrote:
> On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
> Hmm? You assumed, and I quote "there are no such situations
> which would not already have a virtual package". Since there are
> situations where the
On Wed, 26 Sep 2007 04:04:33 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
> On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote:
>> On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
>> > On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote:
>> >> On Sun, 23 Se
mined.
> > - However, since the only files I could imagine being left out of
> > the above transition are ones which arrive with the initial
> > installation of Debian, there should not be many of them.
> >
> > i.e.: afaict, it probably isn't much of a problem
>
I provided that use case. I see no reason to create a virtual
>> package to implement the use case I provided.
>>
>> I ask again, do you have a use case which led you down the path of
>> proposing a virtual package?
> I say again, I have not proposed creating any v
I ask again, do you have a use case which led you down the
> path of proposing a virtual package?
I say again, I have not proposed creating any virtual packages...
> > I have written nothing about "adding a virtual package", and the
> > functionality of the existi
written nothing about "adding a virtual package", and the
> functionality of the existing virtual packages which I would manifest
> is obvious---provide a home for the files "shared by many packages but
> really owned by none."
>> > Perhaps virtual packages need to have a r
so
> no other package is going to depend on it?
Why are you asking that. You provided the use case---"a file shared by
many packages but really owned by none."
I have written nothing about "adding a virtual package", and the
functionality of the existing virtual packages w
gt; by anyone. The same solution would apply, if we could create a
> package for it on the fly.
We can create any number of dummy packages on the fly, but what
is the use case we are trying to solve here? Why are we adding a
virtual package, having package provide the virtual package,
it can not be owned by anyone.
The same solution would apply, if we could create a package for it on
the fly.
Is there any situation where ownership has collided, and a virtual
package is/(could) not (be) Provide:-ed?
[Realizing that discussion about wild ideas is far from sublime, I
decided to p
Roger Leigh <[EMAIL PROTECTED]> writes:
> Following some discussion with Marco d'Itri about inetd, I'd like to
> put forward some more general thoughts on virtual package handling for
> some comments.
>
> Currently, virtual packages (such as mail-transport-
On Wednesday 30 August 2006 00:29, Steve Langasek took the opportunity to say:
> On Tue, Aug 29, 2006 at 01:51:39PM +0200, Magnus Holmgren wrote:
> > On Monday 28 August 2006 21:06, Steve Langasek took the opportunity to
say:
> > > On Mon, Aug 28, 2006 at 04:01:57PM +0200, Magnus Holmgren wrote:
>
On Tue, Aug 29, 2006 at 01:51:39PM +0200, Magnus Holmgren wrote:
> On Monday 28 August 2006 21:06, Steve Langasek took the opportunity to say:
> > On Mon, Aug 28, 2006 at 04:01:57PM +0200, Magnus Holmgren wrote:
> > > Making mail-transport-agent the empty package, and having it depend only
> > > on
On Monday 28 August 2006 21:06, Steve Langasek took the opportunity to say:
> On Mon, Aug 28, 2006 at 04:01:57PM +0200, Magnus Holmgren wrote:
> > Making mail-transport-agent the empty package, and having it depend only
> > on exim4 (the default), should work. Of course, exim4 can't conflict with
>
Magnus Holmgren <[EMAIL PROTECTED]> writes:
> Actually they can, but it's recommended that a real package be given as
> well. From /usr/share/lintian/checks/fields.desc:
> Tag: virtual-package-depends-without-real-package-depends
> Type: warning
> Ref: policy 7.4
> Info: The package declares a de
On Mon, Aug 28, 2006 at 04:01:57PM +0200, Magnus Holmgren wrote:
> Making mail-transport-agent the empty package, and having it depend only on
> exim4 (the default), should work. Of course, exim4 can't conflict with it
> (but it's enough that all the others do),
No, that's not enough. The exim
ackage handling for
> > some comments.
> >
> > Currently, virtual packages (such as mail-transport-agent) cannot be
> > specified by themselves. They can only be used in combination with a
> > non-virtual package which provides the default implementation. For
> > example:
>
&
Roger Leigh wrote:
Hi folks,
Following some discussion with Marco d'Itri about inetd, I'd like to
put forward some more general thoughts on virtual package handling for
some comments.
Currently, virtual packages (such as mail-transport-agent) cannot be
specified by themselves. The
though. It's just a thought.
>
> this way, no virtual package would exist at all.
That would appear to be incorrect. The Debian Policy Manual, § 7.4, defines a
virtual package as "one which appears in the Provides control file field of
another package". It goes on to say th
On 28/08/2006 Magnus Holmgren wrote:
> Making mail-transport-agent the empty package, and having it depend only on
> exim4 (the default), should work. Of course, exim4 can't conflict with it
> (but it's enough that all the others do), so if the default is changed then
> the old default, the new
On Monday 28 August 2006 14:59, Roger Leigh took the opportunity to say:
> For the case of mail-transport-agent, this could be simply solved by
> the creation of a mail-transport-agent-default package. This would
> be an empty package, doing nothing but providing this dependency:
>
> Depends: ex
Hi folks,
Following some discussion with Marco d'Itri about inetd, I'd like to
put forward some more general thoughts on virtual package handling for
some comments.
Currently, virtual packages (such as mail-transport-agent) cannot be
specified by themselves. They can only be used in c
On August 1, 2006 at 1:04PM +0100,
ian (at davenant.greenend.org.uk) wrote:
> Tatsuya Kinoshita writes ("Re: virtual packages `pinentry' and
> `pinentry-x11'"):
> > Hmm, I have not yet understand the policy 3.6:
> >
> > | All packages should use
Tatsuya Kinoshita writes ("Re: virtual packages `pinentry' and `pinentry-x11'"):
> Hmm, I have not yet understand the policy 3.6:
>
> | All packages should use virtual package names where appropriate, and
> | arrange to create new ones if necessa
On 10730 March 1977, Tatsuya Kinoshita wrote:
> | All packages should use virtual package names where appropriate, and
> | arrange to create new ones if necessary. They should not use virtual
> | package names (except privately, amongst a cooperating group of
> | packages) unl
On July 29, 2006 at 4:02PM +0200,
joerg (at debian.org) wrote:
> > At the moment, should `pinentry' be added to the list of virtual
> > package names? If so, I'll file a wishlist bug against debian-policy.
>
> Nope. If it can work as the pinentry thing then provide it. Thats it for you.
Hmm, I h
On 10730 March 1977, Tatsuya Kinoshita wrote:
> At the moment, should `pinentry' be added to the list of virtual
> package names? If so, I'll file a wishlist bug against debian-policy.
Nope. If it can work as the pinentry thing then provide it. Thats it for you.
--
bye Joerg
I read the DUMP an
On July 29, 2006 at 1:18PM +0200,
myon (at debian.org) wrote:
> > Should `pinentry' and `pinentry-x11' be added to the list of
> > virtual package names?
> Policy: 3.6. Virtual packages
>
> All packages should use virtual package names where appropriate, a
y-gtk2 and pinentry-qt, and
> the virtual package `pinentry-x11' is provided by pinentry-gtk,
> pinentry-gtk2 and pinentry-qt, but `pinentry' and `pinentry-x11'
> are not found in the list of virtual package names.
Policy: 3.6. Virtual packages
All packages should use vi
Should `pinentry' and `pinentry-x11' be added to the list of
virtual package names?
I've discovered that the virtual package `pinentry' is provided by
pinentry-curses, pinentry-gtk, pinentry-gtk2 and pinentry-qt, and
the virtual package `pinentry-x11' is provided by pinentry-gtk,
pinentry-gtk2 and
creation
> of the virtual packages mentioned in the policy. I will wait a
> few days before doing any more steps in this regard.
Been a while since I've done anything Schemey, but this looks like a
good proposal.
--
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber:
Note:
This is a repost of the mail at
http://lists.debian.org/debian-devel/2005/04/msg01000.html - no
replies were received at that time. I have now created a bug
report against debian-policy (#310113) requesting the creation
of the virtual packages mentioned in the policy. I will wait
ovides
> > P,
> As a totally offtopic suggestion, how come APT doesn't handle virtual packages
> the way Fink does, where the user gets to choose which virtual package to
> install to satisfy the dependency?
Probably because apt is a back-end (nominally) and so doesn't
Daniel Burrows debian.org> writes:
> When your package Depends upon or Recommends a pure-virtual package P, you
> should always OR the dependency with a dependency on something that provides
> P,
As a totally offtopic suggestion, how come APT doesn't handle virtual packages
Chasecreek Systemhouse <[EMAIL PROTECTED]> writes:
> On Thu, 2 Dec 2004 21:18:12 -0500, Daniel Burrows <[EMAIL PROTECTED]> wrote:
>> I don't understand what this has to do with Gnome or anything I said.
>
> Maybe its just me -- but your statement about selecting a preferred
> package over any ol
Chasecreek Systemhouse <[EMAIL PROTECTED]> schrieb:
> On Thu, 2 Dec 2004 21:18:12 -0500, Daniel Burrows <[EMAIL PROTECTED]> wrote:
>> I don't understand what this has to do with Gnome or anything I said.
>
> Maybe its just me -- but your statement about selecting a preferred
> package over any o
1 - 100 of 131 matches
Mail list logo
