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 03-21-2011, 03:18 PM
Luca Capello
 
Default Library depending on -data packages

Hi there!

Given that I found this problem for the second time in the last 4
months, I think this is worth a discussion on debian-devel@.

It seems that recently two library packages started to change their
Recommends: to common data to a Depends:. This after two bugs were
reported by the same person, Josh Triplett (cc:ed, sorry for the spam),
who asked for an explanation for the Recommends: (a reason which I find
perfectly valid). The two bugs are:

<http://bugs.debian.org/599643>
<http://bugs.debian.org/599666>

When I found out about libm17n-0, I also found out that the change added
a circular dependency and thus commented on this new bug why I think a
library package should not depend on data packages:

<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604926#20>

And now, while looking again for that bug to be linked here, I found
another occurrence of such a situation, reported almost one year ago [1]
by Axel Beckert (cc:ed as well, again sorry for the spam):

<http://bugs.debian.org/582797>

[1] I remember that during one upgrade of emacs-snapshot I was surprised
it pulled anthy-common, but then forgot about reporting it...

I see these situations as a misuse of Depends: where Recommends: would
be perfectly fine, otherwise Recommends: are useless. But given that it
seems no one agrees with me, is such a behavior documented somewhere?

Thx, bye,
Gismo / Luca
 
Old 03-21-2011, 03:42 PM
Simon McVittie
 
Default Library depending on -data packages

On Mon, 21 Mar 2011 at 17:18:00 +0100, Luca Capello wrote:
> When I found out about libm17n-0, I also found out that the change added
> a circular dependency and thus commented on this new bug why I think a
> library package should not depend on data packages

Which way to break the circular dependency needs to be considered case-by-case;
neither answer is universally right.

Sometimes the library (or executable) genuinely does need the data package -
substituting another data set in the same format wouldn't do what its users
expect. The data package typically just takes up space without doing anything
useful if you install it on its own, so it should have the
special::auto-inst-parts debtag and should usually Recommend the library or
executable.

For instance, openarena needs a corresponding version of openarena-data:
if you substitute a data-set in the same format (zipped Quake III-compatible
assets) with non-trivial modifications, it won't be network-compatible, and
might even crash if you don't make corresponding modifications to openarena.
The existence of openarena-data is an implementation detail of openarena,
so it has this relationship:

/--->--- Depends -->---
openarena openarena-data
---<-- Recommends --<--/

Looking at libraries, it seems libgnome2-0 has this relationship with
libgnome2-common.

Sometimes the library or executable can work without the data, but works better
with it (for instance, GLib isn't localized if its -data part is missing).
It recommends the data, and the data can optionally depend on the
library or executable:

/---<--- Depends --<---
libglib2.0-0 libglib2.0-data
--->-- Recommends -->--/

Sometimes the library or executable just needs *some* data in the right format:
it should typically Depend on, or even just Recommend, a virtual package
(with a preferred alternative). For instance, dictd can serve any compatible
dictionary or dictionaries of your choice.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110321164254.GA14545@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110321164254.GA14545@reptile.pseudorandom.co.uk
 
Old 03-21-2011, 04:01 PM
Jonathan Nieder
 
Default Library depending on -data packages

(dropped cc's; hopefully that's okay.)
Hi!

Luca Capello wrote:

> I see these situations as a misuse of Depends: where Recommends: would
> be perfectly fine, otherwise Recommends: are useless. But given that it
> seems no one agrees with me, is such a behavior documented somewhere?

Checking policy, I see:

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

which I grant is not all that helpful. The example I was introduced
to Recommends with is ancient: old X server packages used Recommends
to pull in a font server, because it was possible that your font
server might be running remotely but in all but unusual installations
you want a local one. (Of course nowadays the X server always has a
built-in font server.)

One use of Recommends I agree with is that most latex packages use
Recommends for their documentation (which _has_ to be part of the
default installation according to the license).

So let's just consider your examples.

emacs depends on m17n-db
------------------------
Bug#599643 is about what relationship m17n-lib has to m17n-db. Please
correct me if I'm wrong.

. libm17n provides an API for complex text layout
. m17n-db provides the actual complex layout rules

So, one might conclude, for libm17n to behave as advertised, one *has*
to have m17n-db installed. The DB is just an implementation detail
and could be provided just as well with internal tables in the library.

Wait, wait! But emacs depends on libm17n for complex text layout and
some people are just not going to care. What to do?

Option A. Split the functionality of libm17n-0 into two packages:
(1) libm17n-0-lib, which ensures binaries linked to libm17n-0 can at
least start up correctly and (2) libm17n-0, a dependency package
which depends on libm17n-0-lib and m17n-db and represents the actual
functionality. Change emacs to "Depends: libm17n-0-lib" and
"Suggests: libm17n-0". Make sure the behavior when m17n-db is not
installed is reasonable enough to function ok and to give a hint
that the end-user about what package to ask the sysadmin to install
to get full functionality.

Option B. Make emacs Suggests: and dlopen libm17n, and similarly
make sure the fallback behavior is okay.

Neither involves a Recommends. In either case some basic "task"
package probably ought to Recommends: m17n-db.

Many desktop apps depend on libatk1.0-data
------------------------------------------
Bug#599666 is about what relationship libatk has to libatk-data. Again,
please feel free to correct me if I go wrong.

libatk1.0-data contains soname-independent files which the runtime
libraries need. It consists mostly of locales and is a lot bigger
than the lib itself --- but that does not seem so unusual to me.
Hopefully some day we will find a better way to detail with
localization packaging to avoid wasting so much space.

emacs depends on anthy-common
-----------------------------
Bug#582797 is about dependencies on libm17n implying a much heavier
dependency (anthy) whose functionality is not widely used that way.

The complication (again, as I understand it) is that to demote the
dependency to a Suggests would require finding a good fallback
behavior when it is missing. According to that bug log, libm17n
upstream is working on it.

The plan is for the anthy input module to be in another package that
Depends: libanthy0, if I understand correctly. That input module
could Enhances: libm17n or libm17n could Suggests it.

Hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110321170149.GA7798@elie">http://lists.debian.org/20110321170149.GA7798@elie
 
Old 03-21-2011, 04:10 PM
Jonathan Nieder
 
Default Library depending on -data packages

Hi,

Simon McVittie wrote:

> Which way to break the circular dependency needs to be considered case-by-case;
> neither answer is universally right.

Here (with this statement of the problem) I disagree --- using Depends to
mean Enhances is _always_ wrong.

For example:

> The existence of openarena-data is an implementation detail of openarena,
> so it has this relationship:
>
> /--->--- Depends -->---
> openarena openarena-data
> ---<-- Recommends --<--/

That Recommends should be an Enhances. openarena-data continues to provide
OpenArena game data, regardless of whether openarena is installed (unless I
am missing something, ianal, etc etc).

Thanks for a useful example.
Jonathan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110321170922.GA8076@elie">http://lists.debian.org/20110321170922.GA8076@elie
 
Old 03-21-2011, 04:16 PM
Olaf van der Spek
 
Default Library depending on -data packages

On Mon, Mar 21, 2011 at 5:42 PM, Simon McVittie <smcv@debian.org> wrote:
> The data package typically just takes up space without doing anything
> useful if you install it on its own, so it should have the
> special::auto-inst-parts debtag and should usually Recommend the library or
> executable.

I don't agree. Yes, the data isn't very useful without the code, but
that doesn't mean it should depend or recommend the code.
When you want to play Quake, you don't install Quake-data (or whatever
it's called), you install the pkg containing the executable.

--
Olaf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikFXRFb4-8r5krHc3nq_=vL93ameU9ibzvG+V3e@mail.gmail.com">htt p://lists.debian.org/AANLkTikFXRFb4-8r5krHc3nq_=vL93ameU9ibzvG+V3e@mail.gmail.com
 
Old 03-21-2011, 04:28 PM
Simon McVittie
 
Default Library depending on -data packages

On Mon, 21 Mar 2011 at 12:10:16 -0500, Jonathan Nieder wrote:
> Simon McVittie wrote:
> > The existence of openarena-data is an implementation detail of openarena,
> > so it has this relationship:
> >
> > /--->--- Depends -->---
> > openarena openarena-data
> > ---<-- Recommends --<--/

(It's actually a recommendation of openarena|openarena-server, with >=
versioning, but that's probably not important here.)

> That Recommends should be an Enhances. openarena-data continues to provide
> OpenArena game data, regardless of whether openarena is installed (unless I
> am missing something, ianal, etc etc).

openarena crashes on startup unless you have openarena-data, so, Depends
in that direction. You can't play the game as intended without the
levels/models/textures.

In my opinion, installations of openarena-data should have the OA launcher
scripts and engine, client and/or server, "in all but unusual situations" -
in principle I might want to install openarena-data just so I can look at it,
but in practice I probably want to play (or serve) the game? Or are you saying
that things with special::auto-inst-parts should never have even a weakened
dependency on the package of which they're an implementation detail?

If the Recommends was an Enhances, it'd seem rather redundant, since Enhances
is a "reverse Suggests", openarena already Depends on openarena-data and
Depends is stronger than Suggests?

In situations where the data and the engine have a many-to-many relationship
(the various Doom engines, each of which can play Doom, Doom II, FreeDoom or
FreeDM), I agree that that Recommends might be too strong.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110321172842.GA16700@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110321172842.GA16700@reptile.pseudorandom.co.uk
 
Old 03-21-2011, 06:18 PM
Jonathan Nieder
 
Default Library depending on -data packages

Simon McVittie wrote:

> Or are you saying
> that things with special::auto-inst-parts should never have even a weakened
> dependency on the package of which they're an implementation detail?

Yes. (Well, a Suggests is okay.)

> In situations where the data and the engine have a many-to-many relationship
> (the various Doom engines, each of which can play Doom, Doom II, FreeDoom or
> FreeDM), I agree that that Recommends might be too strong.

That's why I care.[1]

It seems unlikely that another game is going to start using openarena's
data without the engine but still it is nice to leave the possibility
open.

Regards,
Jonathan

[1] The package now called suckless-tools used to Recommends: dwm,
since its raison d'Ítre was to provide basic functionality for that
window manager. This meant:

- for dwm users, not much. APT's "markauto" functionality already
ensured that dwm-tools would be uninstalled once dwm is removed.

- for xmonad users, installing dwm-tools for dmenu would pull in an
extra window manager.

(Side note: suckless-tools is plenty of fun on its own anyway.)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110321191822.GA4051@elie">http://lists.debian.org/20110321191822.GA4051@elie
 
Old 03-21-2011, 09:48 PM
Josh Triplett
 
Default Library depending on -data packages

On Mon, Mar 21, 2011 at 05:18:00PM +0100, Luca Capello wrote:
> Given that I found this problem for the second time in the last 4
> months, I think this is worth a discussion on debian-devel@.

I agree.

> It seems that recently two library packages started to change their
> Recommends: to common data to a Depends:. This after two bugs were
> reported by the same person, Josh Triplett (cc:ed, sorry for the spam),

I appreciate the CC.

> who asked for an explanation for the Recommends: (a reason which I find
> perfectly valid). The two bugs are:
>
> <http://bugs.debian.org/599643>
> <http://bugs.debian.org/599666>
>
> When I found out about libm17n-0, I also found out that the change added
> a circular dependency and thus commented on this new bug why I think a
> library package should not depend on data packages:
>
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604926#20>
>
> And now, while looking again for that bug to be linked here, I found
> another occurrence of such a situation, reported almost one year ago [1]
> by Axel Beckert (cc:ed as well, again sorry for the spam):
>
> <http://bugs.debian.org/582797>
>
> [1] I remember that during one upgrade of emacs-snapshot I was surprised
> it pulled anthy-common, but then forgot about reporting it...
>
> I see these situations as a misuse of Depends: where Recommends: would
> be perfectly fine, otherwise Recommends: are useless. But given that it
> seems no one agrees with me, is such a behavior documented somewhere?

Some of these cases might require Depends, and some might require
Recommends. I don't necessarily know why the libraries might need the
data packages, hence my bug reports asking for an explanation for the
Recommends. I still don't know the answer, since the libraries changed
to use Depends rather than documenting the Recommends.

If a library really does *require* the corresponding data package in
order to do its job for programs that link to it, then the library
should have a Depends on the data package. Since some of our packaging
tools apparently don't always cope well with circular dependencies, and
since the data package doesn't really serve any function on its own (so
people won't install it directly), the data package need not have a
Depends on the library.

If the library does not *require* the data to do its job for programs
that link to it, and some subset of cases can work without the data
package installed, then the library could have a Recommends on the data
package instead. If so, that means many people (using the default
settings of the package management tools) will still get the data
package installed by default, and some people (myself included) will end
up choosing whether to install it or not. For that matter, packages
depending on the library might potentially need to make that decision as
well, based on what subset of the library's functionality they use. It
would help greatly if the library package documented under what
circumstances the library needs the data package, to help people decide
if they fit in the subset of cases where the library will function
without it.

The package description seems like the right place to put such
information, since users will see it in a package manager when making
installation decisions about the package. From Debian Policy: "The
description should describe the package (the program) to a user (system
administrator) who has never met it before so that they have enough
information to decide whether they want to install it." It seems fairly
natural to extend that to "whether they want to install it and its
dependencies/recommendations/suggests". Many packages already do this,
noting in their description things like "install $FOO if you want
$THIS_PACKAGE to $FOOFUNC". devscripts represents an extreme example,
noting the specific packages needed by every script it installs, but
most packages don't need to go that far. For a simpler example, check
out autoconf, which Suggests autoconf-archive and gives a reason in its
description.

Before apt started installing Recommends by default, Recommends just
represented a stronger form of Suggests, and both only served as a vague
hint in a package manager that "you might (Suggests) or probably will
(Recommends) want this other package too". Apt now distinguishes
Recommends and Suggests by installing Recommends by default. However,
they still represent varying degrees of hints, and packages should still
function if people install only their Depends.

Given that Recommends have become significantly more prevalent since
this change to apt, I do think it would make sense to write down the
moderately common practice of documenting the reasons why users might or
might not want to install the Recommends/Suggests. I don't think this
should go so far as a "must" in Policy, and in general I'd consider this
either a wishlist or at most a normal bug, depending on the
circumstances. I think "should" seems about right.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110321224836.GE14195@feather">http://lists.debian.org/20110321224836.GE14195@feather
 
Old 03-23-2011, 08:08 AM
Goswin von Brederlow
 
Default Library depending on -data packages

Simon McVittie <smcv@debian.org> writes:

> For instance, openarena needs a corresponding version of openarena-data:
> if you substitute a data-set in the same format (zipped Quake III-compatible
> assets) with non-trivial modifications, it won't be network-compatible, and
> might even crash if you don't make corresponding modifications to openarena.
> The existence of openarena-data is an implementation detail of openarena,
> so it has this relationship:
>
> /--->--- Depends -->---
> openarena openarena-data
> ---<-- Recommends --<--/

Why should openarena-data recommend openarena? How does the
functionality of openarena-data (provide some chunks of data) in any way
change by having openarena installed or not? It doesn't suddenly become
better in providing the data.

I feel that -data and -common packages are obviously enough auxilary
packages which only use is to provide for their main package that we do
not have to overly fear users installing only the -data package and
wndering why the game doesn't work. The recommends seems totaly
unneccessary.

Further, why is the Recommends versioned? Does that even have any affect
at all? Will "apt-get install openarena-data" with recommends enabled
update an older openarena because the recommends lists a newer version.
(Well, it does because of the Breaks. But lets say we only had
Recommends. What then?)


MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipvab3vk.fsf@frosties.localnet">http://lists.debian.org/87ipvab3vk.fsf@frosties.localnet
 
Old 03-23-2011, 08:20 AM
Goswin von Brederlow
 
Default Library depending on -data packages

Jonathan Nieder <jrnieder@gmail.com> writes:

> (dropped cc's; hopefully that's okay.)
> Hi!
>
> Luca Capello wrote:
>
>> I see these situations as a misuse of Depends: where Recommends: would
>> be perfectly fine, otherwise Recommends: are useless. But given that it
>> seems no one agrees with me, is such a behavior documented somewhere?
>
> Checking policy, I see:
>
> The Recommends field should list packages that would be found
> together with this one in all but unusual installations.
>
> which I grant is not all that helpful.


Look at it from an installing point of view. When installing foo should
also install bar in all but unusual installations then "foo Recomends:
bar" is the right thing.

In the case of a foo-data package recommending the foo package I would
say that that users should not install foo-data but install foo in all
but unusual circumstances. Since foo-data will not be installed directly
but allways through foo the question of wether it should recommend foo
becomes pointless. Yes, foo-data will nearly always be found together
with foo simply because foo depends on foo-data.

Imho we really don't want a recommends for reverse depends. Or do you
think libc6 should recommend coreutils because they will allways be
found together?

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ei5yb3ci.fsf@frosties.localnet">http://lists.debian.org/87ei5yb3ci.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 04:45 PM.

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