I demand that Scott Kitterman may or may not have written...
> On Wednesday, May 25, 2011 08:17:51 AM Darren Salt wrote:
>> I demand that Carsten Hey may or may not have written...
>> [snip]
>>> The third example with indirections would have advantages if one l10n
>>> package contains the translat
On Wednesday, May 25, 2011 08:17:51 AM Darren Salt wrote:
> I demand that Carsten Hey may or may not have written...
>
> [snip]
>
> > The third example with indirections would have advantages if one l10n
> > package contains the translations for multiple packages (which seems to
> > be planned).
I demand that Carsten Hey may or may not have written...
[snip]
> The third example with indirections would have advantages if one l10n
> package contains the translations for multiple packages (which seems to
> be planned).
... which is something which, as upstream for a few packages, I'm not ke
David Kalnischkies writes:
> environment. I can already hear someone asking for
> Package: libc6
> Recommends: libc6-686 {arch::supports:cmov}
> which soon evolves to a complete language in which you really need
> all the funky stuff like & and | and ! together with hard/soft constraints
That c
* Eugene V. Lyubimkin [2011-05-22 18:08 +0300]:
> On 2011-05-22 16:07, Carsten Hey wrote:
> > 'Enhances:', 'Provides', 'Conflicts' and 'Breaks' also require extensive
> > scanning in the package database.
>
> Conflicts and Breaks do not. So, yes, partly true. I personally don't
> want one more reve
* David Kalnischkies [2011-05-23 16:31 +0200]:
> On Sun, May 22, 2011 at 16:07, Carsten Hey wrote:
> > * Conflicts, Breaks, ..., Enhances:
> > - satisfied if any of the clauses is true
>
> Uhm, a Conflicts/Breaks is satisfied if all clauses are false.
This misunderstanding is caused by the unc
On Mon, May 23, 2011 at 18:41, Simon McVittie wrote:
> However, consider gstreamer0.10-pulseaudio: it's a plugin for GStreamer
> applications to output audio through the PulseAudio daemon. Neither GStreamer
> nor PulseAudio should depend on the other: GStreamer applications can equally
> well use
On Mon, 23 May 2011 at 16:31:10 +0200, David Kalnischkies wrote:
> A plugin like xul-ext-firegpg (removed & discontinued upstream) enhances
> iceweasel and depends on gpg. Still, i don't think it would be a good
> idea to add something like 'Recommended-By: iceweasel & gpg'
> as this promotes this
On Mon, May 23, 2011 at 06:50, Miles Bader wrote:
> I've noticed many cases where packages recommend a bunch of stuff that,
> while it might be very nice for some users, really isn't of general
> interest.
So, because package maintainers don't read and understand the policy
which defines clearly
On Sun, May 22, 2011 at 16:07, Carsten Hey wrote:
> * Conflicts, Breaks, ..., Enhances:
> - satisfied if any of the clauses is true
Uhm, a Conflicts/Breaks is satisfied if all clauses are false.
That way you could say Conflicts = ! Pre-Depends.
(regarding "…": Replaces doesn't fit to well in h
On Sat, May 21, 2011 at 17:56, Carsten Hey wrote:
> With above exclamation mark syntax, we could also express "weak
> conflicts", e.g.:
>
> Package: X
> Recommends: !Y
>
> Apt would remove Y by default if X gets installed, but users could
> overwrite this.
As a user i hate it then
Josselin Mouette writes:
> Package: A
> Recommends: A-plugin-B {B}
> APT would be made to install A-plugin-B by default, but only if B is
> installed too. In addition, it would also have to install it while
> pulling B if A is already here.
It would be very nice!
I've noticed man
"Eugene V. Lyubimkin" writes:
>> > > and secondly, this is easily abusable by third-package maintainers
>> > > and even packages from completely different, non-Debian
>> > > repositories:
>> > >
>> > > Package: some-package
>> > > Depends: gnome
>> > > Recommended-When: gnome
>>
>> Third-party r
On 21/05/11 12:24, Josselin Mouette wrote:
Therefore, I’m wondering whether it would be possible to extend the
syntax of Recommends to allow for conditional dependencies. For example,
IANADD, however...
In database terms you're talking about a separate table that stores N:N
relationships,
so
> > > and secondly, this is easily abusable by third-package maintainers
> > > and even packages from completely different, non-Debian
> > > repositories:
> > >
> > > Package: some-package
> > > Depends: gnome
> > > Recommended-When: gnome
>
> Third-party repositories have root access on your syst
On 2011-05-22 16:07, Carsten Hey wrote:
> > > Putting my 'developer of unpopular package manager' on: no, no, pretty
> > > please, no reverse-Recommends. Firstly, one doesn't want to scan all
> > > package database to find all Recommends for the particular package,
>
> 'Enhances:', 'Provides', 'C
* Goswin von Brederlow [2011-05-22 11:55 +0200]:
> "Eugene V. Lyubimkin" writes:
>
> > On 2011-05-21 21:41, Ian Jackson wrote:
> >> Simpler than this, and simpler than constructions involving negations
> >> (which would be very troublesome for the resolution algorithms), would
> >> be:
> >>
> >>
Den 21. mai 2011 13:24, skrev Josselin Mouette:
> * Do you think it would be useful?
For the Wine packages, it would certainly be mighty useful.
Except, of course, that multiarch would make such a thing less effective
on amd64, since cross-arch deps are not supported, and so users will
sti
"Eugene V. Lyubimkin" writes:
> On 2011-05-21 21:41, Ian Jackson wrote:
>> Simpler than this, and simpler than constructions involving negations
>> (which would be very troublesome for the resolution algorithms), would
>> be:
>>
>> Package: A-plugin-B
>> Depends: A, B
>> Recommended-When:
On 2011-05-21 21:41, Ian Jackson wrote:
> Simpler than this, and simpler than constructions involving negations
> (which would be very troublesome for the resolution algorithms), would
> be:
>
> Package: A-plugin-B
> Depends: A, B
> Recommended-When: A, B
Putting my 'developer of unpopular
Josselin Mouette writes ("Conditional Recommends"):
> Therefore, I?m wondering whether it would be possible to extend the
> syntax of Recommends to allow for conditional dependencies. For example,
> in this case:
> Package: A
> Recommends: A-plugin-B {
verwrite this.
Is there any need for such a weak conflict, e.g., to get rid of gcc-4.4
if gcc-4.5 gets installed? Apt's autoremove feature presumably already
handles most of these cases.
If we add conditional recommends and there is a need for weak conflicts,
I think we should choose
On 2011-05-21, Josselin Mouette wrote:
> * Does it make any sense at all?=20
> * Do you think it would be useful?=20
I do think it makes sense and is useful.
> * If not, what could be done for the aforementioned issues?
I have mostly thought about the 'translation pack' issues
Hi all,
in Debian many packages have a fine granularity, which is a very good
thing. Unfortunately there is a drawback; when you install two programs
A and B that are designed to interact together, often the piece of code
that makes them interact together is in a separate package (A-plugin-B)
that
24 matches
Mail list logo
