|
Home > Archive > Debian Developers > July 2005 > Getting rid of circular dependencies
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Getting rid of circular dependencies
|
|
| Bill Allombert 2005-06-24, 6:00 pm |
| Dear Debian developers,
Following a post to Debian-Devel-Announce, I would like to
discuss getting rid of circular dependencies.
Why ?
-----
1) The semantic of Depends specified by Debian policy 7.2. does not allow
packages with circular dependencies to be installed at all:
`Depends'
This declares an absolute dependency. A package will not be
configured unless all of the packages listed in its `Depends'
field have been correctly configured.
This mean that dpkg have to go out of its way to install them, and doing
that break the expectation of packages expecting Depended package to be
configured before them.
2) There have been lots of evidence that circular dependencies create
problems during upgrade. See bugs #310490 in particular
<20050528194731.GF1055@seventeen>.
3) Circular dependencies make the job of the testing scripts harder.
4) Circular dependencies make bootstrapping a new plateform harder.
5) There is an urban legend that circular dependencies between packages
build from the same source are harmless. This is false of course. Being
part of the same source package has no effect of the Packages.gz file
whatsoever.
Which ?
-------
Preferably all of them.
Robert Lemmen was kind enough to set up a summary of current circular
dependencies: <http://debian.semistable.com/debgraph.out>
See the list for yourself.
The circular dependencies involving the largest number of packages are:
* libxtst6 libxtrap6 libxrandr2 libxp6 libxt6 libxmu6 libxi6 libxrender1
libxft1 libsm6 xlibs
* libgnorba27 libgnomeui32 libgnomesupport0 gnome-bin gnome-libs-data libgnome32
* xemacs21-gnome-nomule xemacs21-gnome-mule-canna-wnn xemacs21-gnome-mule
xemacs21-nomule xemacs21-mule-canna-wnn xemacs21-bin xemacs21-support
xemacs21-mule xemacs21
* gnome-panel-data gnome-panel nautilus gnome-control-center capplets
gnome-session
* phpgroupware-preferences phpgroupware-admin phpgroupware-setup
phpgroupware-phpgwapi phpgroupware
* wesnoth-tdh wesnoth-ei wesnoth-sotbe wesnoth-trow wesnoth-httt
wesnoth-data wesnoth
How ?
-----
I see two easy case:
1) foo and foo-data. There is usualy no reason for foo-data to depend on
foo. foo-data does not provide user-visible interface, only data, so it
does not need to depend on foo.
2) libfoo and foo-bin, where foo-bin include binaries linked with
libfoo. Usually libfoo only need to Depends on configuration data
in foo-bin and not on any binaries linked with libfoo (to avoid infinite
recursion). In that case it should be possible to split foo-bin in
foo-bin and foo-common, and change libfoo to depend on foo-common
instead.
Other options ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ondrej Sury 2005-06-24, 6:00 pm |
| On Fri, 2005-06-24 at 17:21 +0200, Bill Allombert wrote:
>
> 1) foo and foo-data. There is usualy no reason for foo-data to depend
> on foo. foo-data does not provide user-visible interface, only data,
> so it does not need to depend on foo.
This is usually used as way how to also uninstall foo-data when you
uninstall foo.
But I agree that this is just cosmetic compared to problems created by
circular dependencies...
Ondrej.
--
Ondrej Sury <ondrej@sury.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Petri Latvala 2005-06-24, 6:00 pm |
| On Fri, Jun 24, 2005 at 05:30:08PM +0200, Ondrej Sury wrote:
> On Fri, 2005-06-24 at 17:21 +0200, Bill Allombert wrote:
>
> This is usually used as way how to also uninstall foo-data when you
> uninstall foo.
>
> But I agree that this is just cosmetic compared to problems created by
> circular dependencies...
It is an abuse of the Depends field. foo-data doesn't *need* foo for
its own operations. Nothing in -data fails to execute without foo
(because there's just data, nothing to execute). If the Depends is
there to make foo-data automatically uninstalled when foo is
uninstalled, then trust aptitude to do its dirty deeds. Or maybe we
need a new field for that purpose that only has effect on uninstalls, like
Uninstall-with: foo
If the purpose was to make foo installed when a user installs foo-data
himself, then Recommend instead.
--
Petri Latvala
| |
| Peter Samuelson 2005-06-24, 6:00 pm |
|
[Petri Latvala]
> It is an abuse of the Depends field. foo-data doesn't *need* foo for
> its own operations. Nothing in -data fails to execute without foo
> (because there's just data, nothing to execute).
Depends does not just mean "executables will crash or fail to load".
It actually means "it is pointless to install this package without this
other package". Having a package removed automatically because it no
longer has any reason to be installed is a perfectly legitimate use for
"Depends".
That does not solve the circular dependency problem, granted. Perhaps
there is need of a package flag that says "it is pointless to have this
package installed by itself, so remove it if nothing depends on it".
aptitude currently deduces this from its auto-install state flag, but
perhaps a package itself ought to be allowed to express it.
> Or maybe we need a new field for that purpose that only has effect on
> uninstalls, like Uninstall-with: foo
That's an alternative. Or a field (call it "Post-Depends") which means
the same as Depends except that dpkg is told not to worry about the
install/remove ordering - in other words, it's given a hint about where
it can safely break the ordering loop. (Currently it has to guess.)
| |
| Olaf van der Spek 2005-06-24, 6:00 pm |
| On 6/24/05, Peter Samuelson <peter@p12n.org> wrote:
>=20
> [Petri Latvala]
>=20
> Depends does not just mean "executables will crash or fail to load".
> It actually means "it is pointless to install this package without this
> other package". Having a package removed automatically because it no
I'd classify that as abuse.
A data package doesn't require another package to do it's duties
(since it has no duties of it's own) so there shouldn't be a depends.
> longer has any reason to be installed is a perfectly legitimate use for
> "Depends".
>=20
> That does not solve the circular dependency problem, granted. Perhaps
> there is need of a package flag that says "it is pointless to have this
> package installed by itself, so remove it if nothing depends on it".
> aptitude currently deduces this from its auto-install state flag, but
> perhaps a package itself ought to be allowed to express it.
>=20
>=20
> That's an alternative.
What if you introduce a new package (bar) that also depends on
foo-data? Then you're forced to also install foo, although you don't
need it at all?
| |
| Santiago Vila 2005-06-24, 6:00 pm |
| On Fri, 24 Jun 2005, Peter Samuelson wrote:
> Depends does not just mean "executables will crash or fail to load".
> It actually means "it is pointless to install this package without this
> other package".
I think we should not use such meaning for the Depends field.
Otherwise we could end up having control files like this:
Package: libfoo
Depends: complete-or'ed-list-of-all-packages-which-depend-on-libfoo
> [...] Perhaps there is need of a package flag that says "it is
> pointless to have this package installed by itself, so remove it if
> nothing depends on it".
We already have something for that. It's called "Section: libs"
and deborphan, and it works great.
Perhaps we should just move to section libs any package which is
useless by itself, and it's only useful in combination with others,
much like libraries, but without requiring them to be real libraries.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Petri Latvala 2005-06-24, 6:00 pm |
| On Fri, Jun 24, 2005 at 07:39:16PM +0200, Santiago Vila wrote:
> We already have something for that. It's called "Section: libs"
> and deborphan, and it works great.
>
> Perhaps we should just move to section libs any package which is
> useless by itself, and it's only useful in combination with others,
> much like libraries, but without requiring them to be real libraries.
That would then be an abuse of the section field. A data package is
not a lib.
How about a field (or a debtag) useless-alone, which deborphan and
aptitude and whatnot can garbage-collect when nothing depends on such
a package? That would solve the problem with Uninstall-with: foo when
another package suddenly needs the data package.
--
Petri Latvala
| |
| Bill Allombert 2005-06-24, 6:00 pm |
| On Fri, Jun 24, 2005 at 11:36:16AM -0500, Peter Samuelson wrote:
>
> [Petri Latvala]
>
> Depends does not just mean "executables will crash or fail to load".
> It actually means "it is pointless to install this package without this
> other package". Having a package removed automatically because it no
> longer has any reason to be installed is a perfectly legitimate use for
> "Depends".
No it is not. Read Debian Policy 7.2:
`Depends'
This declares an absolute dependency. A package will not be
configured unless all of the packages listed in its `Depends'
field have been correctly configured.
The `Depends' field should be used if the depended-on package is
required for the depending package to provide a significant
amount of functionality.
The `Depends' field should also be used if the `postinst',
`prerm' or `postrm' scripts require the package to be present in
order to run. Note, however, that the `postrm' cannot rely on
any non-essential packages to be present during the `purge'
phase.
If you want to remove useless package, use aptitude debfoster or
deborphan. dpkg will _never_ do it for you. apt-get will try to do it
but at the expense of considerable breakage risk. Bug #310490 show
an example where the risk is to remove every KDE packages.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter Samuelson 2005-06-24, 6:00 pm |
|
[Bill Allombert]
> The `Depends' field should be used if the depended-on package is
> required for the depending package to provide a significant
> amount of functionality.
I'd say if a -data package is useless without its corresponding binary
package, that fits this definition just fine. Policy does not specify
*why* a package might fail to provide significant functionality without
the presence of something else. (Unless you wish to argue that -data
packages provide no functionality, which seems a pretty arbitrary
definition of 'functionality'.)
However, that's rather beside the point. I'd be happy to concede that
Depends should have a narrower definition, if a 'Useless-Alone' or
'Keep-Orphan' field/tag could be introduced to cover the -data case.
Hmmm, what's the story with fields versus tags for boolean properties?
"Essential" is a field, but people are now talking about tags for this
sort of thing instead.
> If you want to remove useless package, use aptitude debfoster or
> deborphan. dpkg will _never_ do it for you. apt-get will try to do it
> but at the expense of considerable breakage risk. Bug #310490 show an
> example where the risk is to remove every KDE packages.
I read that wrong at first and thought that KDE was what you meant by
"useless packages". (:
| |
| Bill Allombert 2005-06-24, 6:00 pm |
| On Fri, Jun 24, 2005 at 07:39:16PM +0200, Santiago Vila wrote:
>
> Perhaps we should just move to section libs any package which is
> useless by itself, and it's only useful in combination with others,
> much like libraries, but without requiring them to be real libraries.
Good idea. Or we could have a new section for architecture independant data.
Moving everything which is not mean to be directly installed by users
in it, so the section games only contains actual games and not the data
files.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Olaf van der Spek 2005-06-24, 6:00 pm |
| On 6/24/05, Peter Samuelson <peter@p12n.org> wrote:
>=20
> [Bill Allombert]
is[vbcol=seagreen]
>=20
> I'd say if a -data package is useless without its corresponding binary
> package, that fits this definition just fine. Policy does not specify
> *why* a package might fail to provide significant functionality without
> the presence of something else. (Unless you wish to argue that -data
> packages provide no functionality, which seems a pretty arbitrary
> definition of 'functionality'.)
I'd argue for exactly that.
What functionality would you say a data package provides?
It's the other package that provides the functionality, not the data
package. The data package shouldn't even have to know about the other
package.
| |
| Ondrej Sury 2005-06-24, 6:00 pm |
| On Fri, 2005-06-24 at 22:59 +0200, Olaf van der Spek wrote:
>
> I'd argue for exactly that.
> What functionality would you say a data package provides?
>
> It's the other package that provides the functionality, not the data
> package. The data package shouldn't even have to know about the other
> package.
If you want to play word games and not apply common sense, then I would
say that foo-data package has functionality to provide data to foo and
so it's broken without foo package. You must realize that 90% of these
packages are games and only reason for foo + foo-data is to not split
out arch independent data out of foo package so it doesn't get
replicated for each arch.
One thing is very clear:
1. this is (a sort of) abuse of Depends field
2. we need reverse Suggest/Recommends field, ie. something like
Recommends-Uninstall: foo-data
(well, same can be applied to -doc, -common, etc.)
Truth is that deborphan is very nice tool to do this...
Ondrej.
--
Ondrej Sury <ondrej@sury.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Olaf van der Spek 2005-06-24, 6:00 pm |
| On 6/24/05, Ondrej Sury <ondrej@sury.org> wrote:
> On Fri, 2005-06-24 at 22:59 +0200, Olaf van der Spek wrote:
>=20
> If you want to play word games and not apply common sense, then I would
It's not a word game at all.
> say that foo-data package has functionality to provide data to foo and
But that 'functionality' doesn't break without foo.
Like I said before, what would you do if there also was a foo2 or bar
(independent of foo) that'd use foo-data?
Whatever you tried to achieve with the reverse dependency would not
work in that case.
| |
| Olaf van der Spek 2005-06-24, 6:00 pm |
| On 6/24/05, Ondrej Sury <ondrej@sury.org> wrote:
> so it's broken without foo package. You must realize that 90% of these
> packages are games and only reason for foo + foo-data is to not split
> out arch independent data out of foo package so it doesn't get
> replicated for each arch.
Hmm, another way to nicely solve that would be to improve the
smartness of the archive software such that it deals with this
'replication' under the hood.
| |
| John H. Robinson, IV 2005-06-24, 6:00 pm |
| Bill Allombert wrote:
>
> 1) foo and foo-data. There is usualy no reason for foo-data to depend on
> foo. foo-data does not provide user-visible interface, only data, so it
> does not need to depend on foo.
Fully agree. Looking at one of the circular dependencies listed on
http://debian.semistable.com/debgraph.out I chose amphetamine{,-data} as
an example.
The list of files for amphetamine-data shows everything is in /usr/share
except /etc/amphetamine/{amph,user}.conf. I do not know enough about the
game to know if the configuration file is more closely related to the
binary, or to the dataa itself. I would venture to guess that the conf
files are more closely related to the game's binary.
I can see where the game would be installed on the client system, and
the data would live on the file server under /usr/share. Currently, the
only way to do this is by having installed broken packages, and to copy
the /etc/amphetamine files from the filer onto the client.
vim and vim-common seem to suffer the same, except vim-common has
nothing outside the /usr/share directory. In my case, though, I would
likely have installed vim onto the filer, also.
--
John H. Robinson, IV jaqque@debian.org
http ((((
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html ((((
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter Samuelson 2005-06-24, 6:00 pm |
|
[Olaf van der Spek]
> Hmm, another way to nicely solve that would be to improve the
> smartness of the archive software such that it deals with this
> 'replication' under the hood.
Sounds like you want some sort of transparent jigdo on each mirror.
That, or explicit support everywhere for multi-file debian packages,
similar in spirit to .dsc source packages. Neither sounds like much
fun.
| |
| Olaf van der Spek 2005-06-24, 6:00 pm |
| On 6/25/05, John H. Robinson, IV <jaqque@debian.org> wrote:
> I can see where the game would be installed on the client system, and
> the data would live on the file server under /usr/share. Currently, the
> only way to do this is by having installed broken packages, and to copy
> the /etc/amphetamine files from the filer onto the client.
Why would you only install the data and not the binaries on the file
server (filer?)?
=20
> vim and vim-common seem to suffer the same, except vim-common has
> nothing outside the /usr/share directory. In my case, though, I would
> likely have installed vim onto the filer, also.
| |
| Olaf van der Spek 2005-06-24, 6:00 pm |
| On 6/25/05, Peter Samuelson <peter@p12n.org> wrote:
>=20
> [Olaf van der Spek]
>=20
> Sounds like you want some sort of transparent jigdo on each mirror.
> That, or explicit support everywhere for multi-file debian packages,
> similar in spirit to .dsc source packages. Neither sounds like much
> fun.
What's no fun about the transparent jigdo-like approach?
| |
| Peter Samuelson 2005-06-24, 8:48 pm |
|
[Olaf van der Spek]
> What's no fun about the transparent jigdo-like approach?
Explaining to each one of the countless mirror admins just how to load
a custom CGI program, apache module, apache2 module, and/or FTP daemon.
And explaining why they have to.
| |
| Junichi Uekawa 2005-06-25, 2:49 am |
| | |
| Bill Allombert 2005-06-25, 7:48 am |
| On Sat, Jun 25, 2005 at 02:43:28PM +0900, Junichi Uekawa wrote:
>
>
> However, we have some users randomly filing bugs on
> foo-data that doesn't get uninstalled if it's no longer useful.
Fix the users, then!
>
> I'm rather doubtful it should be easy to fix this situation.
> I doubt having configuration data in foo-bin is a good idea,
> since it will generally cause problems when
> libfoo1/libfoo2 needs to coexist.
If it is not a good idea, all the more reason to introduce foo-common ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Lionel Elie Mamane 2005-06-26, 2:48 am |
| On Sat, Jun 25, 2005 at 02:43:28PM +0900, Junichi Uekawa wrote:
[vbcol=seagreen]
> However, we have some users randomly filing bugs on
> foo-data that doesn't get uninstalled if it's no longer useful.
Have these users use aptitude.
--
Lionel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-06-26, 7:48 am |
| > >> 1) foo and foo-data. There is usualy no reason for foo-data to
>
>
> Have these users use aptitude.
Document *that* in the policy; or you can monitor debian-bugs-dist
and stamp on every bug resembling that.
We are quite a distributed bunch of folks.
regards,
junichi
--
Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2005-06-26, 7:48 am |
| > >
>
> If it is not a good idea, all the more reason to introduce foo-common ?
>
For a package of 'daemon with a shared library interface'
it seems to be logical to have a package for the
daemon and the shared library, yet they would
probably be logical to depend on each other.
In the case of mysql/pgsql, the shared libraries
don't depend on the database; may be a good idea to
extend this; but some shared libraries simply don't
function without the daemon.
In that case, it might be better to make it
into a single package.
I have in mind jackd/libjack as an example,
which currently only have recommends on jackd.
regards,
junichi
--
Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Filippo Giunchedi 2005-06-26, 5:54 pm |
| Junichi Uekawa wrote on 26-06-2005 11:32:
>
>
> Document *that* in the policy; or you can monitor debian-bugs-dist
> and stamp on every bug resembling that.
maybe the policy is not the right place to document that, it would be
better to expand developer's reference 6.7.5 (architecture-indipendent
data) to include best practices while packaging data so foo-data doesn't
depend on foo.
Also, including a mention to use aptitude if "foo-data doesn't
automatically gets uninstalled while removing foo" is better suited for
debian-faq or debian user's guide (I'm filing bugs for both)
filippo
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2005-06-26, 5:54 pm |
| * Petri Latvala (petri.latvala@realityescape.net) [050624 17:57]:
> On Fri, Jun 24, 2005 at 05:30:08PM +0200, Ondrej Sury wrote:
>
> It is an abuse of the Depends field. foo-data doesn't *need* foo for
> its own operations. Nothing in -data fails to execute without foo
> (because there's just data, nothing to execute). If the Depends is
> there to make foo-data automatically uninstalled when foo is
> uninstalled, then trust aptitude to do its dirty deeds. Or maybe we
> need a new field for that purpose that only has effect on uninstalls, like
> Uninstall-with: foo
Uninstall-with is perhaps a bit bad.
However, Depends has two semantics
* Need the package during run-time
* order of configuration
Perhaps the first one should be available by itself as field "Needs".
Cheers,
Andi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Paul TBBle Hampson 2005-06-27, 7:56 am |
| On Sat, Jun 25, 2005 at 02:43:28PM +0900, Junichi Uekawa wrote:
> 2. helper information to allow tools like deborphan to work correctly.
What about adding a 'data' section, parallel to 'libs', which deborphan also
lists by default?
It wouldn't solve every case, but it certainly seems like a good place to file
*-data packages.
I think requiring a program to be installed to keep a data package installed is
daft. If I pick a hypothetical example, if we required a dictionary to be
installed at the same time as edict, then edict couldn't be used by local
scripts without dragging in unused dictionary software.
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------
| |
| Gustavo Noronha Silva 2005-06-27, 5:54 pm |
| Em Sex, 2005-06-24 Ã_s 17:30 +0200, Ondrej Sury escreveu:
> On Fri, 2005-06-24 at 17:21 +0200, Bill Allombert wrote:
>
> This is usually used as way how to also uninstall foo-data when you
> uninstall foo.
>
> But I agree that this is just cosmetic compared to problems created by
> circular dependencies...
This should really be fixed in the packaging tool -- aptitude will
handle this very elegantly, maybe bringing its expanded package states
to libapt itself would be nice -- rather than using this kind of trick.
See ya,
--
kov@debian.org: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
| |
| Adrian von Bidder 2005-06-27, 5:54 pm |
| | |
| Gustavo Noronha Silva 2005-06-27, 5:54 pm |
| Em Sex, 2005-06-24 Ã_s 23:57 +0200, Ondrej Sury escreveu:
> One thing is very clear:
>
> 1. this is (a sort of) abuse of Depends field
Yes.
> 2. we need reverse Suggest/Recommends field, ie. something like
> Recommends-Uninstall: foo-data
No, all we need is a better handling of what we have today in our
package managers (read APT frontends). A -data package should not really
be presented to the user as something that might add functionality to
his system, but simply as a 'helper package' for another one.
Having a separate 'data' section and telling package managers to
'second-class' libs, data and some other fields might be a good idea.
> (well, same can be applied to -doc, -common, etc.)
doc is a different problem IMO, it does provide functionality, even on
systems which do not have 'foo' installed. You might want to take a look
at apache's docs from your workstation while working on a server over
ssh and there are many other examples of use for the doc case.
See ya,
--
kov@debian.org: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
| |
| John H. Robinson, IV 2005-06-27, 5:54 pm |
| Olaf van der Spek wrote:
> On 6/25/05, John H. Robinson, IV <jaqque@debian.org> wrote:
>
> Why would you only install the data and not the binaries on the file
> server (filer?)?
Because you are sharing /usr/share and not /usr ?
FHS 2.3:
/usr/share : Architecture-independent data
One filer to rule all the architectures. Essentially, the same reason we
make -data packages to begin with. If you have a mixed environment (x86,
amd64, sparc, ppc) then you can have one /usr/share for all of them.
--
John H. Robinson, IV jaqque@debian.org
http ((((
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html ((((
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Olaf van der Spek 2005-06-27, 5:54 pm |
| On 6/27/05, John H. Robinson, IV <jaqque@debian.org> wrote:
> Olaf van der Spek wrote:
he[vbcol=seagreen]
py[vbcol=seagreen]
>=20
> Because you are sharing /usr/share and not /usr ?
>=20
> FHS 2.3:
> /usr/share : Architecture-independent data
>=20
> One filer to rule all the architectures. Essentially, the same reason we
What is a filer?
> make -data packages to begin with. If you have a mixed environment (x86,
> amd64, sparc, ppc) then you can have one /usr/share for all of them.
I understand that part, but I'd expect binaries to be able to live on
a file servers too, even for multiple architectures.
| |
| John H. Robinson, IV 2005-06-27, 5:54 pm |
| Olaf van der Spek wrote:
> On 6/27/05, John H. Robinson, IV <jaqque@debian.org> wrote:
>
> What is a filer?
A file server.
>
> I understand that part, but I'd expect binaries to be able to live on
> a file servers too, even for multiple architectures.
/usr/bin/vim is different on PPC than on i386. You cannot share /usr
(and thusly /usr/bin) between architectures. You can with /usr/share, as
it is architecture independent.
--
John H. Robinson, IV jaqque@debian.org
http ((((
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html ((((
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Olaf van der Spek 2005-06-27, 5:54 pm |
| On 6/27/05, John H. Robinson, IV <jaqque@debian.org> wrote:
>=20
> /usr/bin/vim is different on PPC than on i386. You cannot share /usr
Sure.=20
> (and thusly /usr/bin) between architectures. You can with /usr/share, as
> it is architecture independent.
I guess the tools aren't capable of this, but AFAIK you could just do
(manually) something like /usr/i386/bin and /usr/ppc/bin
And then the client could map /usr/bin to either depending on it's architec=
ture.
| |
| Roger Leigh 2005-06-27, 5:54 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Olaf van der Spek <olafvdspek@gmail.com> writes:
> On 6/27/05, John H. Robinson, IV <jaqque@debian.org> wrote:
>
> I guess the tools aren't capable of this, but AFAIK you could just do
> (manually) something like /usr/i386/bin and /usr/ppc/bin
The whole cpu-manfr-opsys triplet would be better.
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFCwGJMVcFcaSW/uEgRAriMAJ0YU6TtmeRW+qkRqOQLtz6kK/19+QCgpzjk
pXJqACsbJaQT4vq+1mvBy9w=
=wA6L
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John H. Robinson, IV 2005-06-27, 5:54 pm |
| Roger Leigh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Olaf van der Spek <olafvdspek@gmail.com> writes:
>
This is a bit more complicated than a simpt dpkg -i, and far more
difficult to remove.
[vbcol=seagreen]
> The whole cpu-manfr-opsys triplet would be better.
If you wanted to go that route, and you had spare room on the filer, you
could effectively do chroots of entire systems.
/vol/redhat-advanced-server-x86
/vol/debian-sarge-i386
/vol/debian-sarge-ppc
/vol/ubuntu-hoary-ppc
Or whatever scheme you want to use.
--
John H. Robinson, IV jaqque@debian.org
http ((((
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html ((((
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kevin Mark 2005-06-27, 8:48 pm |
| On Mon, Jun 27, 2005 at 02:28:30PM -0300, Gustavo Noronha Silva wrote:
> Em Sex, 2005-06-24 às 23:57 +0200, Ondrej Sury escreveu:
>
> Yes.
>
>
> No, all we need is a better handling of what we have today in our
> package managers (read APT frontends).
Hi Gustavo,
I think that makes sense. apt frontends should have a 'user' setting
that only shows apps and an 'expert' setting that shows libs,
-common,-data. I will check the bugs.d.o and see if anyone has files a
wishlist bug.
Cheers,
Kev
--
counter.li.org #238656 -- goto counter.li.org and be counted!
`$' $'
$ $ _
,d$$$g$ ,d$$$b. $,d$$$b`$' g$$$$$b $,d$$b
,$P' `$ ,$P' `Y$ $$' `$ $ "' `$ $$' `$
$$ $ $$ggggg$ $ $ $ ,$P"" $ $ $
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $ $
`Y$$P'$. `Y$$$$P $$$P"' ,$. `Y$$P'$ $. ,$.
| |
| Adeodato Simó 2005-06-28, 7:50 am |
| * Bill Allombert [Fri, 24 Jun 2005 13:36:39 -0500]:
> On Fri, Jun 24, 2005 at 07:39:16PM +0200, Santiago Vila wrote:
[vbcol=seagreen]
> Good idea. Or we could have a new section for architecture independant data.
> Moving everything which is not mean to be directly installed by users
> in it, so the section games only contains actual games and not the data
> files.
I support this proposal, at least as an interim solution till we can
have something better (e.g., package management tools being aware of a
certain debtag). And as somebody mentioned elsewhere in the thread,
together with documentation in our user guide and FAQ about the
markauto feature of aptitude, and deborphan/debfoster.
I'd like to hear from ftpmaster (CC'ed) if, provided this solution
gains some acceptance, they'd be willing to help with a mass-change in
the override files (see numbers below), and/or with the creation of
such new section.
Thanks.
% grep-dctrl <SID -Fpackage -e '.*-data$' -ns section | sort | uniq -c | sort -rn
79 games
14 libs
11 gnome
10 graphics
6 science
5 x11
5 misc
5 kde
4 utils
4 text
4 net
4 math
3 devel
2 admin
1 web
1 tex
1 sound
% grep-dctrl <SID -Fpackage -e '.*-common$' -ns section | sort | uniq -c | sort -rn
27 net
21 misc
20 libs
15 editors
14 devel
13 games
12 web
12 python
11 x11
10 text
9 admin
6 utils
6 interpreters
5 science
5 mail
5 gnome
4 sound
3 math
3 doc
2 graphics
1 tex
1 otherosfs
1 libdevel
1 embedded
1 comm
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Experience is something you don't get until just after you need it.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jeroen van Wolffelaar 2005-06-28, 7:50 am |
| On Tue, Jun 28, 2005 at 11:57:25AM +0200, Adeodato Sim? wrote:
> I'd like to hear from ftpmaster (CC'ed) if, provided this solution
> gains some acceptance, they'd be willing to help with a mass-change in
> the override files (see numbers below), and/or with the creation of
> such new section.
Sure, it seems logical to add some new sections, like for java, ruby
and 'data' -- though keep in mind that nothing has been decided on this
yet.
When a set of new sections has been decided on, there will naturally be
some mass-override-change to get existing packages in the correct
section.
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josselin Mouette 2005-06-28, 7:50 am |
| Le vendredi 24 juin 2005 =E0 17:21 +0200, Bill Allombert a =E9crit :
> I see two easy case:
>=20
> 1) foo and foo-data. There is usualy no reason for foo-data to depend on
> foo. foo-data does not provide user-visible interface, only data, so it
> does not need to depend on foo.
>=20
> 2) libfoo and foo-bin, where foo-bin include binaries linked with
> libfoo. Usually libfoo only need to Depends on configuration data
> in foo-bin and not on any binaries linked with libfoo (to avoid infinite
> recursion). In that case it should be possible to split foo-bin in
> foo-bin and foo-common, and change libfoo to depend on foo-common
> instead.
How would you treat the librsvg case? Currently, librsvg2-2 and
librsvg2-common both depend on each other. The librsvg2-2 package
contains the library, and librsvg2-common contains a loader that allows
gdk_pixbuf to load SVG files.
* librsvg2-common needs to depend on librsvg2-2 because it links to the
library;
* librsvg2-2 depends on librsvg2-common because most applications
linking to librsvg2 also expect the SVG loader to be available.
Similarly, how would you treat the fontconfig case? Currently,
libfontconfig1 contains the library, while fontconfig contains the
shared configuration and support binaries (including fc-cache).
* fontconfig depends on libfontconfig1 because it links to it;
* libfontconfig1 depends on fontconfig because the applications using
libfontconfig1 are almost unusable if fc-cache isn't run in the font
directories.
The libgtk2.0-0/libgtk2.0-bin case is very similar: without running
update-gdkpixbuf-loaders, applications using libgtk2.0-0 won't work.
The gconf package contains a daemon that links to libgconf2-4. However
applications linking to libgconf2-4 will require that daemon to be
installed. The same holds for libgnomevfs2-common/libgnomevfs2-0.
In short, there are cases where circular dependencies are needed. Fixing
the problem means fixing the tools, not the packages. (Which doesn't
mean we shouldn't fix packages when it's possible; the GNOME
panel/session/nautilus/control-center mess was fixed, for example.)
--=20
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Olaf van der Spek 2005-06-28, 7:50 am |
| On 6/28/05, Josselin Mouette <joss@debian.org> wrote:
> How would you treat the librsvg case? Currently, librsvg2-2 and
> librsvg2-common both depend on each other. The librsvg2-2 package
> contains the library, and librsvg2-common contains a loader that allows
> gdk_pixbuf to load SVG files.
> * librsvg2-common needs to depend on librsvg2-2 because it links to the
> library;
> * librsvg2-2 depends on librsvg2-common because most applications
> linking to librsvg2 also expect the SVG loader to be available.
So they expect something to be available without depending on a
package that provides it? Sounds like a bug.
| |
| Bill Allombert 2005-06-28, 7:50 am |
| On Tue, Jun 28, 2005 at 01:46:06PM +0200, Josselin Mouette wrote:
> Le vendredi 24 juin 2005 à 17:21 +0200, Bill Allombert a écrit :
>
> How would you treat the librsvg case? Currently, librsvg2-2 and
> librsvg2-common both depend on each other. The librsvg2-2 package
> contains the library, and librsvg2-common contains a loader that allows
> gdk_pixbuf to load SVG files.
> * librsvg2-common needs to depend on librsvg2-2 because it links to the
> library;
> * librsvg2-2 depends on librsvg2-common because most applications
> linking to librsvg2 also expect the SVG loader to be available.
> Similarly, how would you treat the fontconfig case? Currently,
> libfontconfig1 contains the library, while fontconfig contains the
> shared configuration and support binaries (including fc-cache).
> * fontconfig depends on libfontconfig1 because it links to it;
> * libfontconfig1 depends on fontconfig because the applications using
> libfontconfig1 are almost unusable if fc-cache isn't run in the font
> directories.
> The libgtk2.0-0/libgtk2.0-bin case is very similar: without running
> update-gdkpixbuf-loaders, applications using libgtk2.0-0 won't work.
>
> The gconf package contains a daemon that links to libgconf2-4. However
> applications linking to libgconf2-4 will require that daemon to be
> installed. The same holds for libgnomevfs2-common/libgnomevfs2-0.
In all that cases, you can _either_:
1) include the offending binary (e.g. fc-cache) in the library package.
2) document that packages using some extra feature (e.g. SVG loader)
needs to depend on an extra package (librsvg2-common)
3) change the shlibs file to document the dependency on the library, e.g
change libfontconfig1.shlibs to
libfontconfig 1 libfontconfig1 (>= 2.3.0), fontconfig
and rebuild every package using libfontconfig. At this point you can
remove the circular dependency.
4) split the library in two libraries so that the -common package depend
only on the first and is used only by the second.
5) A better solution I trust you to propose.
> In short, there are cases where circular dependencies are needed. Fixing
> the problem means fixing the tools, not the packages.
I disagree. I think we can find technical way to get rid of every
circular dependencies, but I have no hope to find even in theory a
process to handle them that would be reliable. The process of deciding
whether a set of package, when circular dependencies are involved, can be
installed together is NP-complete.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josselin Mouette 2005-06-28, 5:55 pm |
| Le mardi 28 juin 2005 =E0 14:51 +0200, Bill Allombert a =E9crit :
> 1) include the offending binary (e.g. fc-cache) in the library package.
No. See policy, =A78.2.
> 2) document that packages using some extra feature (e.g. SVG loader)
> needs to depend on an extra package (librsvg2-common)
Guess why we moved from doing things this way to make librsvg2-2 depend
on librsvg2-common...
> 3) change the shlibs file to document the dependency on the library, e.g
> change libfontconfig1.shlibs to
> libfontconfig 1 libfontconfig1 (>=3D 2.3.0), fontconfig
> and rebuild every package using libfontconfig. At this point you can
> remove the circular dependency.
This is complete overkill. It makes assumptions on the current
implementation, and it brings dependencies that should be purely
indirect. The program only actually uses libfontconfig1, so it should
only depend on libfontconfig1.
> 4) split the library in two libraries so that the -common package depend
> only on the first and is used only by the second.
This one would be good. In fact, maybe linking to the library isn't
necessary in these packages, I'll have a closer look. In this case using
--as-needed would solve the problem.
--=20
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Josselin Mouette 2005-06-28, 5:55 pm |
| Le mardi 28 juin 2005 =E0 16:05 +0200, Josselin Mouette a =E9crit :
>=20
> Guess why we moved from doing things this way to make librsvg2-2 depend
> on librsvg2-common...
To make things clearer: there is no way to tell whether a program
actually needs librsvg2-common. Even testing it with and without
librsvg2-common installed wouldn't be enough, as it could e.g. make use
of themes that include SVG files.
d[vbcol=seagreen]
>=20
> This one would be good. In fact, maybe linking to the library isn't
> necessary in these packages, I'll have a closer look. In this case using
> --as-needed would solve the problem.
A closer look at the involved symbols shows that this wouldn't be an
easy task, as the symbols needed by the daemon are also needed by the
applications. Moving a part of the symbols to another library would mean
adding another package, making applications also depend on this package
through the shlibs mechanism. In the end, such a split wouldn't mean
anything, as the three packages (library, daemon, "light" library) would
end up being installed together in all cases.
In the case of gconf2 and gnome-vfs2, I see no point in removing the
circular dependencies. Gconf2 needs its library to work, and the library
needs the daemon to work. It's not like data packages, where the data
doesn't really need the program. The only solution without circular
dependencies is to put the daemon and the library in a single package.
However this is forbidden by policy.
--=20
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Bill Allombert 2005-06-28, 5:55 pm |
| On Tue, Jun 28, 2005 at 04:05:55PM +0200, Josselin Mouette wrote:
> Le mardi 28 juin 2005 à 14:51 +0200, Bill Allombert a écrit :
>
> No. See policy, §8.2.
You could ship fc-cache as /usr/lib/libfontconfig1/fc-cache
so it will not need to conflict with libfontconfig2.
>
> Guess why we moved from doing things this way to make librsvg2-2 depend
> on librsvg2-common...
I will certainly not hazard a guess.
>
> This one would be good. In fact, maybe linking to the library isn't
> necessary in these packages, I'll have a closer look. In this case using
> --as-needed would solve the problem.
Thanks for looking at it!
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony DeRobertis 2005-06-28, 5:55 pm |
| Josselin Mouette wrote:
> Le mardi 28 juin 2005 =E0 16:05 +0200, Josselin Mouette a =E9crit :
>=20
[vbcol=seagreen]
>=20
>=20
> To make things clearer: there is no way to tell whether a program
> actually needs librsvg2-common. Even testing it with and without
> librsvg2-common installed wouldn't be enough, as it could e.g. make use=
> of themes that include SVG files.
Wouldn't that at most be a Recommends, or even a Suggests?
| |
| Steve Langasek 2005-06-28, 5:55 pm |
| On Tue, Jun 28, 2005 at 06:30:32PM +0200, Bill Allombert wrote:
> On Tue, Jun 28, 2005 at 04:05:55PM +0200, Josselin Mouette wrote:
[vbcol=seagreen]
> You could ship fc-cache as /usr/lib/libfontconfig1/fc-cache
> so it will not need to conflict with libfontconfig2.
But then packages that need fc-cache have an additional burden of updating
the path to fc-config every time the soname changes. These circular deps
aren't pretty, but I don't see that any of the alternatives are actually
better.
--
Steve Langasek
postmodern programmer
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bill Allombert 2005-06-28, 5:55 pm |
| On Tue, Jun 28, 2005 at 02:56:54PM -0700, Steve Langasek wrote:
> On Tue, Jun 28, 2005 at 06:30:32PM +0200, Bill Allombert wrote:
>
>
> But then packages that need fc-cache have an additional burden of updating
> the path to fc-config every time the soname changes.
Packages needing fc-cache outside of libfontconfig1 can use the symlink
/usr/bin/fc-cache -> /usr/lib/libfontconfig1/fc-cache provided by
fontconfig (which they already depends on). fontconfig will of course
depend on libfontconfig1 (as it already do).
We only want to get rid of the libfontconfig1 depending on fontconfig.
libfontconfig1 will be able to call /usr/lib/libfontconfig1/fc-cache
without fontconfig itself being installed.
> These circular deps
> aren't pretty, but I don't see that any of the alternatives are actually
> better.
Unless you propose some ways to handle circular deps reliably, it is not an
esthetic issue at all.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josselin Mouette 2005-06-29, 7:53 am |
| Le mardi 28 juin 2005 =E0 14:48 -0400, Anthony DeRobertis a =E9crit :
>=20
> Wouldn't that at most be a Recommends, or even a Suggests?
Wait, I have a better idea: why not split all the gdk-pixbuf loaders in
separate packages? Packages using PNG themes or icons would only need to
depend on libgdkpixbuf-loader-png, while packages using XPM icons would
only need libgdkpixbuf-loader-xpm and packages using JPEG backgrounds
would require libgtkpixbuf-loader-jpeg. This would save a few kilobytes
on the hard disk drives of users wanting to install libgtk2.0-0 without
installing any application that depends on it.
To make things less sarcastic: more and more themes or backgrounds are
using SVG files. Applications using GTK2 don't really *need*
librsvg2-common, but it should nevertheless be installed every time
libgtk2.0-0 is installed, so that the SVG format is always supported.
However that would introduce a circular dependency between gtk+2.0 and
librsvg2, which would be even worse.
--=20
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Steve Langasek 2005-06-29, 8:48 pm |
| On Wed, Jun 29, 2005 at 12:17:28AM +0200, Bill Allombert wrote:
> On Tue, Jun 28, 2005 at 02:56:54PM -0700, Steve Langasek wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> Packages needing fc-cache outside of libfontconfig1 can use the symlink
> /usr/bin/fc-cache -> /usr/lib/libfontconfig1/fc-cache provided by
> fontconfig (which they already depends on). fontconfig will of course
> depend on libfontconfig1 (as it already do).
> We only want to get rid of the libfontconfig1 depending on fontconfig.
> libfontconfig1 will be able to call /usr/lib/libfontconfig1/fc-cache
> without fontconfig itself being installed.
Ah, quite -- sorry for not reading more closely.
[vbcol=seagreen]
> Unless you propose some ways to handle circular deps reliably, it is not an
> esthetic issue at all.
The actual impact in this case is minimal, AFAIK.
--
Steve Langasek
postmodern programmer
| |
| Bill Allombert 2005-06-30, 6:02 pm |
| On Wed, Jun 29, 2005 at 04:03:11PM -0700, Steve Langasek wrote:
>
>
> Ah, quite -- sorry for not reading more closely.
So would you consider this as an acceptable option?
>
>
> The actual impact in this case is minimal, AFAIK.
I cannot share you optimism. This circular dep is bug #310877 that I
reported while investigating bug #310490. At that time this
circular dep was really looking harmful.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gustavo Noronha Silva 2005-06-30, 6:02 pm |
| Em Qua, 2005-06-29 Ã_s 13:31 +0200, Josselin Mouette escreveu:
> To make things less sarcastic: more and more themes or backgrounds are
> using SVG files. Applications using GTK2 don't really *need*
> librsvg2-common, but it should nevertheless be installed every time
> libgtk2.0-0 is installed, so that the SVG format is always supported.
> However that would introduce a circular dependency between gtk+2.0 and
> librsvg2, which would be even worse.
Why not simply puting the loader inside the library package? If the
loader should always be together with the library, then make them one
package and be done with it.
I may be missing something obvious, but I don't see the point of having
a -commong package in this case.
See ya,
--
kov@debian.org: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
| |
| Josselin Mouette 2005-06-30, 6:02 pm |
| Le jeudi 30 juin 2005 à 13:12 -0300, Gustavo Noronha Silva a écrit :
> Why not simply puting the loader inside the library package? If the
> loader should always be together with the library, then make them one
> package and be done with it.
>
> I may be missing something obvious, but I don't see the point of having
> a -commong package in this case.
If the library SONAME changes, the loader's filename doesn't need to
change. However, in this case, the two versions of the library must be
able to be installed together, so the loader has to be in a different
package.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Bill Allombert 2005-06-30, 6:02 pm |
| On Tue, Jun 28, 2005 at 02:51:52PM +0200, Bill Allombert wrote:
> In all that cases, you can _either_:
>
> 3) change the shlibs file to document the dependency on the library, e.g
> change libfontconfig1.shlibs to
> libfontconfig 1 libfontconfig1 (>= 2.3.0), fontconfig
> and rebuild every package using libfontconfig. At this point you can
> remove the circular dependency.
I start to believe this is part of the solution if done completly
differently:
Do not change libfontconfig1.shlibs. Instead move the actual library to
a new package libfontconfig1-lib. Provide a (possibly dummy) package
libfontconfig1 that depend on libfontconfig1-lib (=${Source-version}) and
on fontconfig. Change fontconfig to depend on libfontconfig1-lib but not
on libfontconfig1 (overriding the shlibdeps mechanism here).
Alternatively libfontconfig1 can contain fc-cache and support files and
depends on libfontconfig1-lib manually. No override of shlibdeps is
necessary here.
Well at least this is the idea.
If we accept the notion that shlibs must provide all the dependencies
needed to use a library (and not merely the .so.N file), then we need
some leeway to introduce additional dependencies. Since changing .shlibs
file is too costly we need to introduce a virtualisation layer between
packages and the library. Here, the introduction of the dummy
libfontconfig1 achieve that.
This sound ugly now, but merely because it is not in accordance with
usual practice, which probably just means we will need to define new
common practice that handle that cases.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-06-30, 6:02 pm |
| On Thu, Jun 30, 2005 at 05:38:54PM +0200, Bill Allombert wrote:
> On Wed, Jun 29, 2005 at 04:03:11PM -0700, Steve Langasek wrote:
[vbcol=seagreen]
> So would you consider this as an acceptable option?
I don't have any objections to it, yeah.
--
Steve Langasek
postmodern programmer
| |
| Ola Lundqvist 2005-07-03, 5:54 pm |
| Hello
On Fri, Jun 24, 2005 at 05:21:51PM +0200, Bill Allombert wrote:
> Dear Debian developers,
>
> Following a post to Debian-Devel-Announce, I would like to
> discuss getting rid of circular dependencies.
>
> Why ?
> -----
> 1) The semantic of Depends specified by Debian policy 7.2. does not allow
> packages with circular dependencies to be installed at all:
>
> `Depends'
> This declares an absolute dependency. A package will not be
> configured unless all of the packages listed in its `Depends'
> field have been correctly configured.
This phrasing is obviously wrong as you can install packages with
circular dependencies. This phrasing say exactly what Pre-Depends is.
Depends should be described as follows:
`Depends'
This declares an absolute dependency. A package will not be
configured unless all of the packages listed in its `Depends'
field have been correctly unpacked.
But I actually think you may have made a mistake by saying that
configured refer to the configure phase in dpkg install. It could be
clarified though.
> This mean that dpkg have to go out of its way to install them, and doing
> that break the expectation of packages expecting Depended package to be
> configured before them.
>
> 2) There have been lots of evidence that circular dependencies create
> problems during upgrade. See bugs #310490 in particular
> <20050528194731.GF1055@seventeen>.
This may be the case, but I think that this may be a problem in aptitude
more than in the existance of circular dependencies. Well I'm not the
one to determine this.
Removing unneeded circular dependencies is a good thing though. Especially
for big chunks of packages.
> 3) Circular dependencies make the job of the testing scripts harder.
Yes that is true.
> 4) Circular dependencies make bootstrapping a new plateform harder.
True also.
> 5) There is an urban legend that circular dependencies between packages
> build from the same source are harmless. This is false of course. Being
> part of the same source package has no effect of the Packages.gz file
> whatsoever.
It is true for case 3 and 4 above (at least 4 as I not fully sure about case 3).
> Which ?
> -------
>
> Preferably all of them.
>
> Robert Lemmen was kind enough to set up a summary of current circular
> dependencies: <http://debian.semistable.com/debgraph.out>
> See the list for yourself.
>
> The circular dependencies involving the largest number of packages are:
>
> * libxtst6 libxtrap6 libxrandr2 libxp6 libxt6 libxmu6 libxi6 libxrender1
> libxft1 libsm6 xlibs
>
> * libgnorba27 libgnomeui32 libgnomesupport0 gnome-bin gnome-libs-data libgnome32
>
> * xemacs21-gnome-nomule xemacs21-gnome-mule-canna-wnn xemacs21-gnome-mule
> xemacs21-nomule xemacs21-mule-canna-wnn xemacs21-bin xemacs21-support
> xemacs21-mule xemacs21
>
> * gnome-panel-data gnome-panel nautilus gnome-control-center capplets
> gnome-session
>
> * phpgroupware-preferences phpgroupware-admin phpgroupware-setup
> phpgroupware-phpgwapi phpgroupware
>
> * wesnoth-tdh wesnoth-ei wesnoth-sotbe wesnoth-trow wesnoth-httt
> wesnoth-data wesnoth
>
> How ?
> -----
>
> I see two easy case:
>
> 1) foo and foo-data. There is usualy no reason for foo-data to depend on
> foo. foo-data does not provide user-visible interface, only data, so it
> does not need to depend on foo.
>
> 2) libfoo and foo-bin, where foo-bin include binaries linked with
> libfoo. Usually libfoo only need to Depends on configuration data
> in foo-bin and not on any binaries linked with libfoo (to avoid infinite
> recursion). In that case it should be possible to split foo-bin in
> foo-bin and foo-common, and change libfoo to depend on foo-common
> instead.
Regards,
// Ola
> Other options ?
>
> Cheers,
> --
> Bill. <ballombe@debian.org>
>
> Imagine a large red swirl here.
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2005-07-03, 5:54 pm |
| On Sun, Jul 03, 2005 at 04:57:58PM +0200, Ola Lundqvist wrote:
> On Fri, Jun 24, 2005 at 05:21:51PM +0200, Bill Allombert wrote:
>
> This phrasing is obviously wrong as you can install packages with
> circular dependencies. This phrasing say exactly what Pre-Depends is.
>
> Depends should be described as follows:
>
> `Depends'
> This declares an absolute dependency. A package will not be
> configured unless all of the packages listed in its `Depends'
> field have been correctly unpacked.
This is incorrect. Depends is as described in policy, with the addition
that dpkg will arbitrarily break loops.
For the meaning of Pre-Depends, see policy.
--
Colin Watson [cjwatson@debian.org]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ola Lundqvist 2005-07-04, 7:50 am |
| Hello
On Sun, Jul 03, 2005 at 04:39:04PM +0100, Colin Watson wrote:
> On Sun, Jul 03, 2005 at 04:57:58PM +0200, Ola Lundqvist wrote:
>
> This is incorrect. Depends is as described in policy, with the addition
> that dpkg will arbitrarily break loops.
>
> For the meaning of Pre-Depends, see policy.
I stand corrected.
Interesting. Maybe the arbitrary loop thing can be documented too in
the policy, or otherwise it should be not allowed. Interesting that
I have missed this delicate problem.
Actually I think that it should be two types of dependencies. One
for normal dependencies, that is just need the other software unpacked
to work, and one for must not be configured until other ones is
configured. This can probably help a lot.
Regards,
// Ola
>
> --
> Colin Watson [cjwatson@debian.org]
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-04, 7:50 am |
| Junichi Uekawa <dancer@netfort.gr.jp> writes:
>
> However, we have some users randomly filing bugs on
> foo-data that doesn't get uninstalled if it's no longer useful.
We already have debfoster, deborphan and aptitude for this. Also this
applies for libfoo much for than for foo-data packages. That is a
larger problem with existing solutions.
> We need
>
> 1. policy documenting the current decision that foo-data doesn't depend on foo
Policy already forbids circular depends.
> 2. helper information to allow tools like deborphan to work correctly.
>
>
> I'm rather doubtful it should be easy to fix this situation.
> I doubt having configuration data in foo-bin is a good idea,
> since it will generally cause problems when
> libfoo1/libfoo2 needs to coexist.
Might be problematic for multiarch too. You need 32bit and/or 64bit
libfoo packages but only one foo-bin package (usualy). The
configuration will have to work for one or the other or both at the
same time.
But usualy that isn't a problem. It just needs to be thought off and
might force some of the suggested splits into libfoo, foo-bin and
foo-common.
> regards,
> junichi
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-04, 7:50 am |
| Bill Allombert <ballombe@master.debian.org> writes:
> On Fri, Jun 24, 2005 at 07:39:16PM +0200, Santiago Vila wrote:
>
> Good idea. Or we could have a new section for architecture independant data.
> Moving everything which is not mean to be directly installed by users
> in it, so the section games only contains actual games and not the data
> files.
>
> Cheers,
Let me suggest obsoleting sections altogether and getting debtags more
firmly placed into the project. Sections are too limited for the
amount of packages in debian.
E.g. xemacs needs to be in editors, x11, web, news, games and mail
sections.
But that doesn't realy solve the problem on its own. It would be nice
if packages could be consistently taged with "Application:
yes|no|<untaged>" signifying that this package is usefull on its own
(foo), will never be used alone (foo-data, libfoo) or is
ambigious. Frontends should then hide anything with "Application: no"
under normal operations.
I'm wondering if popcon data could be used to see how many users have
package foo installed without anything depending on foo.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-04, 7:50 am |
| Josselin Mouette <joss@debian.org> writes:
> Le jeudi 30 juin 2005 à 13:12 -0300, Gustavo Noronha Silva a écrit :
>
> If the library SONAME changes, the loader's filename doesn't need to
> change. However, in this case, the two versions of the library must be
> able to be installed together, so the loader has to be in a different
> package.
The loaders are plugins, right? (they get dlopened and not exec()ed)
And then you mix two SONAMEs of a library in a single program? I doubt
you get that to work reliable.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-04, 7:50 am |
| Josselin Mouette <joss@debian.org> writes:
> Le vendredi 24 juin 2005 à 17:21 +0200, Bill Allombert a écrit :
>
> How would you treat the librsvg case? Currently, librsvg2-2 and
> librsvg2-common both depend on each other. The librsvg2-2 package
> contains the library, and librsvg2-common contains a loader that allows
> gdk_pixbuf to load SVG files.
> * librsvg2-common needs to depend on librsvg2-2 because it links to the
> library;
> * librsvg2-2 depends on librsvg2-common because most applications
> linking to librsvg2 also expect the SVG loader to be available.
So on all systems both packages will always be installed together. Why
have two packages at all? I would call this a useless split of
packages.
I'm guessing the split is so different librsvg library versions can be
installed in parallel without the SVG loaders colliding. But doesn't
that cause problems when the app and loader use different libs?
Also for multiarch support you will need multiple SVG loaders to be
installable in parallel.
> Similarly, how would you treat the fontconfig case? Currently,
> libfontconfig1 contains the library, while fontconfig contains the
> shared configuration and support binaries (including fc-cache).
> * fontconfig depends on libfontconfig1 because it links to it;
> * libfontconfig1 depends on fontconfig because the applications using
> libfontconfig1 are almost unusable if fc-cache isn't run in the font
> directories.
fontconfig: Depends: libfontconfig1
libfontconfig1: no depends
Add fontconfig to the libfontconfig1.shlibs file.
After all packages have been rebuild you get what you want.
> The libgtk2.0-0/libgtk2.0-bin case is very similar: without running
> update-gdkpixbuf-loaders, applications using libgtk2.0-0 won't work.
Same case as the SVG loader. Merge the two.
> The gconf package contains a daemon that links to libgconf2-4. However
> applications linking to libgconf2-4 will require that daemon to be
> installed. The same holds for libgnomevfs2-common/libgnomevfs2-0.
Same case as fontconfig, add gconf to the shlibs file.
> In short, there are cases where circular dependencies are needed. Fixing
> the problem means fixing the tools, not the packages. (Which doesn't
> mean we shouldn't fix packages when it's possible; the GNOME
> panel/session/nautilus/control-center mess was fixed, for example.)
s/needed/convenient/
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-04, 7:50 am |
| Bill Allombert <allomber@math.u-bordeaux.fr> writes:
> On Tue, Jun 28, 2005 at 02:51:52PM +0200, Bill Allombert wrote:
>
> I start to believe this is part of the solution if done completly
> differently:
>
> Do not change libfontconfig1.shlibs. Instead move the actual library to
> a new package libfontconfig1-lib. Provide a (possibly dummy) package
> libfontconfig1 that depend on libfontconfig1-lib (=${Source-version}) and
> on fontconfig. Change fontconfig to depend on libfontconfig1-lib but not
> on libfontconfig1 (overriding the shlibdeps mechanism here).
I like that.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-04, 7:50 am |
| Ola Lundqvist <opal@debian.org> writes:
> Hello
>
> On Sun, Jul 03, 2005 at 04:39:04PM +0100, Colin Watson wrote:
>
> I stand corrected.
>
> Interesting. Maybe the arbitrary loop thing can be documented too in
> the policy, or otherwise it should be not allowed. Interesting that
> I have missed this delicate problem.
>
> Actually I think that it should be two types of dependencies. One
> for normal dependencies, that is just need the other software unpacked
> to work, and one for must not be configured until other ones is
> configured. This can probably help a lot.
>
> Regards,
>
> // Ola
More usefull is probably a new type 'needs <foo> to run but can be
configured without'. The effect would be just like Depends except that
cycles can be safely broken at that point.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josselin Mouette 2005-07-04, 5:58 pm |
| Le lundi 04 juillet 2005 à 11:00 +0200, Goswin von Brederlow a écrit :
>
> So on all systems both packages will always be installed together. Why
> have two packages at all? I would call this a useless split of
> packages.
>
> I'm guessing the split is so different librsvg library versions can be
> installed in parallel without the SVG loaders colliding. But doesn't
> that cause problems when the app and loader use different libs?
Indeed, as librsvg doesn't use versioned symbols.
> Also for multiarch support you will need multiple SVG loaders to be
> installable in parallel.
This isn't an issue, as AIUI multiarch brings them in separate toplevel
${libdir} directories.
> fontconfig: Depends: libfontconfig1
> libfontconfig1: no depends
> Add fontconfig to the libfontconfig1.shlibs file.
>
> After all packages have been rebuild you get what you want.
I hate that solution, as it makes programs depend on a different package
from the library they are actually using.
The /usr/lib/libfontconfig1/fc-cache solution is much cleaner.
>
> Same case as the SVG loader. Merge the two.
It would violate a "must" directive in the policy. Please change the
policy first.
>
> Same case as fontconfig, add gconf to the shlibs file.
No. The real solution is a merge of the two packages, but it isn't as
easy as you'd like it to.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Russ Allbery 2005-07-04, 5:58 pm |
| Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
> But that doesn't realy solve the problem on its own. It would be nice if
> packages could be consistently taged with "Application:
> yes|no|<untaged>" signifying that this package is usefull on its own
> (foo), will never be used alone (foo-data, libfoo) or is
> ambigious. Frontends should then hide anything with "Application: no"
> under normal operations.
This is a really interesting idea, particularly if it were combined with
an implementation recommendation to stop suppressing Application: no
packages if they're listed in Suggests of an installed package or list an
installed package in Enhances. That way, documentation packages could be
listed in Suggests but otherwise be Application: no, since the sort of
user who doesn't want to see all the library packages is probably also not
going to want to browse the list of documentation packages for packages
they don't have installed.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-04, 8:51 pm |
| Russ Allbery <rra@stanford.edu> writes:
> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
>
>
> This is a really interesting idea, particularly if it were combined with
> an implementation recommendation to stop suppressing Application: no
> packages if they're listed in Suggests of an installed package or list an
> installed package in Enhances. That way, documentation packages could be
> listed in Suggests but otherwise be Application: no, since the sort of
> user who doesn't want to see all the library packages is probably also not
> going to want to browse the list of documentation packages for packages
> they don't have installed.
Or a "Package-Type: application | lib | data | doc | dev | common |
dummy". A yes/no field is hard to extend to more cases.
As a bonus the 'Package-Type: dummy" would be packages needed to
handle package renames or replacements and can be savely purged on the
next aptitude/debfoster/deborphan run.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| John H. Robinson, IV 2005-07-05, 5:57 pm |
| Goswin von Brederlow wrote:
> Russ Allbery <rra@stanford.edu> writes:
>
>
> Or a "Package-Type: application | lib | data | doc | dev | common |
> dummy". A yes/no field is hard to extend to more cases.
I like this idea. Frontends can then display the useful set
(application, possibly doc) by default, and leave the others hidden. As
long as the frontends were configurable to display all packages, then I
will be happy.
I dislike it when things try to be smarter than me. I don't mind
helpful, but I do mind condescention.
> As a bonus the 'Package-Type: dummy" would be packages needed to
> handle package renames or replacements and can be savely purged on the
> next aptitude/debfoster/deborphan run.
This would be very useful, indeed. It would have to be careful that the
dummy pcakges were indeed not needed anymore. Sounds like more state in
the frontend.
Do aptitude/debfoster/deborphan use the same database for metadata? Is
there any way that they could? Would this even be wise?
While I do find the above idea very useful, how does it help with the
circular dependency issue? Could there be another tag
``In-Case-Of-Circular-Dependecy-Install-Me-First: True'' ? This would
help in the case of *known* circular dependencies, and it leaves the
thinking up to a human (or perhaps an autobuilder that has attempted
various means of installing the circularly dependent packages, and
determined a working method) instead of leaving it up to the client
system to guess.
I'd like to see a linda/lintian warning for such things. In the case of
application and application-lib built from the same source, this is
easy. When you have applications outside of the source package, then it
would get a bit tougher. Can linda/lintian be extended to read the dpkg
database, to seek circular dependencies? Again, is this something
useful?
--
John H. Robinson, IV jaqque@debian.org
http ((((
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html ((((
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-05, 8:48 pm |
| "John H. Robinson, IV" <jaqque@debian.org> writes:
> Goswin von Brederlow wrote:
>
> This would be very useful, indeed. It would have to be careful that the
> dummy pcakges were indeed not needed anymore. Sounds like more state in
> the frontend.
For aptitude the dummy package would just become automatic while the
package(s) the dummy package depends on should become the state the
dummy package was before the upgrade.
The dummy package would then get removed when nothing depends on it.
> Do aptitude/debfoster/deborphan use the same database for metadata? Is
> there any way that they could? Would this even be wise?
No. Not yet? It certainly would be nice if they could.
> While I do find the above idea very useful, how does it help with the
> circular dependency issue? Could there be another tag
> ``In-Case-Of-Circular-Dependecy-Install-Me-First: True'' ? This would
> help in the case of *known* circular dependencies, and it leaves the
> thinking up to a human (or perhaps an autobuilder that has attempted
> various means of installing the circularly dependent packages, and
> determined a working method) instead of leaving it up to the client
> system to guess.
It would solve the problem of abusing Depends to get packages removed
automaticaly when one of a pair gets removed.
> I'd like to see a linda/lintian warning for such things. In the case of
> application and application-lib built from the same source, this is
> easy. When you have applications outside of the source package, then it
> would get a bit tougher. Can linda/lintian be extended to read the dpkg
> database, to seek circular dependencies? Again, is this something
> useful?
Having apt/dpkg refuse to install those (warn about it for a while
first) will clean those up quick enough.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kevin Mark 2005-07-06, 2:49 am |
| On Tue, Jul 05, 2005 at 10:36:49AM -0700, John H. Robinson, IV wrote:
> Goswin von Brederlow wrote:
<cool new tags for package-type idea>[vbcol=seagreen]
>
> While I do find the above idea very useful, how does it help with the
> circular dependency issue? Could there be another tag
> ``In-Case-Of-Circular-Dependecy-Install-Me-First: True'' ? This would
> help in the case of *known* circular dependencies, and it leaves the
> thinking up to a human (or perhaps an autobuilder that has attempted
> various means of installing the circularly dependent packages, and
> determined a working method) instead of leaving it up to the client
> system to guess.
>
Hi John,
It seem from my observations that the debian release process has several
'hint's used: unstable to testing(britney), what not to build for arch x(wanna-build),
linda/lintian check. It would seem to follow: to hint for known
circular dependencies.
Cheers,
Kev
--
counter.li.org #238656 -- goto counter.li.org and be counted!
`$' $'
$ $ _
,d$$$g$ ,d$$$b. $,d$$$b`$' g$$$$$b $,d$$b
,$P' `$ ,$P' `Y$ $$' `$ $ "' `$ $$' `$
$$ $ $$ggggg$ $ $ $ ,$P"" $ $ $
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $ $
`Y$$P'$. `Y$$$$P $$$P"' ,$. `Y$$P'$ $. ,$.
| |
| Paul TBBle Hampson 2005-07-06, 2:49 am |
| On Tue, Jul 05, 2005 at 10:36:49AM -0700, John H. Robinson, IV wrote:
> Goswin von Brederlow wrote:
[vbcol=seagreen]
> While I do find the above idea very useful, how does it help with the
> circular dependency issue? Could there be another tag
> ``In-Case-Of-Circular-Dependecy-Install-Me-First: True'' ? This would
> help in the case of *known* circular dependencies, and it leaves the
> thinking up to a human (or perhaps an autobuilder that has attempted
> various means of installing the circularly dependent packages, and
> determined a working method) instead of leaving it up to the client
> system to guess.
The discussion that prompted the above is that many circular dependancies are
caused by -data pacakges depending on -bin packages of tools to utilise that
data, so that the data packages are not left lying around on the system if the
tools are removed. The above addresses _those_ circular dependancies, because
it gives more data to the tools about what's independantly less useful than
the current 'libs' section, (as used by deborphan for this purpose).
(As far as this set is concerned, I feel that Depends _should_ mean "This
doesn't work at all without that" rather than "This is useless without that".
And data, as far as I'm concerned, works by its very existance, even if the
right tool is not immediately at hand.)
There's another, more difficult class of circular dependancies which involves
parallel-installable shared library packages depending on a common binary,
which depends on one of the parallel-installable shared libraries. Or something
like that, anyway. ^_^
The above doesn't address this second class at all, as far as I can see, but
some kind of solution seems to have been come up with, at least for fontconfig.
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------
| |
| Thomas Hood 2005-07-06, 5:53 pm |
| Goswin von Brederlow wrote:
> More usefull is probably a new type 'needs <foo> to run but can be
> configured without'. The effect would be just like Depends except
> that cycles can be safely broken at that point.
For symmetry you might want to call the dependency you describe
'Post-Depends'.
X Pre-Depends: Y = X unpack needs Y config'ed
X Depends: Y = X config needs Y config'ed
X Post-Pepends: Y = X run needs Y config'ed
To break a cyclical Dependency, one of the Depends in the cycle could
be weakened to a Post-Depends; then dpkg would know to configure the
Depended-upon package before configuring the other (merely
Post-Depended-upon) package.
I agree that mutual dependencies can be appropriate when two packages
work closely together. An example is a program that consists of both
binaries and scripts which run one another in complex ways and the
scripts and data have been split off into a separate Arch: all package.
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|