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 02-27-2011, 02:44 PM
Petter Reinholdtsen
 
Default Are circular dependencies inside a source package OK?

[Lucas Nussbaum]
> However, that creates many small dependency cycles. I am under the
> impression that dependency cycles are considered bad, but that we
> have many of them already, and that no important part of our
> infrastructure or tools really has problems with them. Also, they
> are limited to a single source package here.
>
> Is there a good reason not to do the above?

Dependency loops tend to break in edge cases, and I have run into a few:

- Installing a lot of packages (~1000 packages done by Debian Edu), a
while back caused the set of packages to be installed to be split
into lumps, and some times this installation would fail because the
split would happen in the middle of such loop. I believe a
workaround/fix for this has been implemented, but do not know the
details.

- When installing several packages and one of the packages fail to
install, the recovery system for dpkg/apt fail and leave the system
in an inconsistent state because only some of the packages in such
loop have been unpacked and configured.

- Piuparts is not able to come up with a sensible order to test
packages when there are dependency loops. A workaround has been
implemented. Suspect packages with loops are simply never tested
by piuparts

All of these issues might of cause be seen as not important parts of
our infrastructure or not important problems, but I believe they are
enough to still consider package dependency loops a bad idea.

Are there other problems with dependency loops?

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2flk4glzdm5.fsf@login2.uio.no">http://lists.debian.org/2flk4glzdm5.fsf@login2.uio.no
 
Old 02-27-2011, 04:56 PM
Josselin Mouette
 
Default Are circular dependencies inside a source package OK?

Le dimanche 27 février 2011 * 16:31 +0100, Lucas Nussbaum a écrit :
> Ideally, we would have binary packages named like that:
> ruby-foo: arch-indep part of the foo library
> ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
> ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1
> jruby-foo: arch-dep part of the foo library, built for jruby
> rubinius-foo: arch-dep part of the foo library, built for rubinius
>
> But then, we have a problem, because:
> - ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo,
> rubinius-foo) installed to work correctly
> - ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo
> installed

Which size is ruby-foo? If it’s not significant, you’re probably wasting
your time.

> What we would like to do to reflect this is:
> - ruby-foo depend on the implementation-specific package for the default
> version of Ruby (so Depends: ruby1.8-foo)
> - ruby<interpreter_version>-foo Depends: ruby-foo
> However, that creates many small dependency cycles. I am under the
> impression that dependency cycles are considered bad, but that we have
> many of them already, and that no important part of our infrastructure
> or tools really has problems with them. Also, they are limited to a
> single source package here.

Circular dependencies, in the same source package or not, tend to create
a lot of breakage, especially at uninstall time - partly because dpkg
doesn’t cope well with them.

> Is there a good reason not to do the above?

Yes: circular dependencies are bad. They make the dependency resolver’s
behavior less predictable, and they cause various bugs since postinst
and prerm scripts are run in random order. Triggers often hide these
bugs, but the conceptual problem is still here.

If you really want to split the arch-indep parts, you should create:
- ruby-foo-common containing the arch-indep part;
- ruby1.8-foo (and so on) containing the arch-dependent part;
- ruby-foo which is an empty package depending on ruby1.8-foo.

The simpler solution is to copy the arch-dependent parts in all binary
packages.

--
.'`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`- […] I will see what I can do for you.” -- Jörg Schilling
 
Old 02-28-2011, 11:47 AM
Holger Levsen
 
Default Are circular dependencies inside a source package OK?

Hi,

circular dependencies are bad for a variety of reasons already explained here
(plus probably some others), but...

On Sonntag, 27. Februar 2011, Petter Reinholdtsen wrote:
> - Piuparts is not able to come up with a sensible order to test
> packages when there are dependency loops. A workaround has been
> implemented. Suspect packages with loops are simply never tested
> by piuparts

...piuparts in master-slave mode can (barely) cope with them now, using a list
provided at http://debian.semistable.com/debgraph.out.html - see the piuparts
0.39 changelog about #526046 for more info.

(The sensible order to test packages with circular depends IMO is to pick one
randomly. If the test fails (due to problems in the circular dependend
packages), all of these packages will fail anyway, and if it passes, well,
all will pass ;-)

Sill, the implemented solution is definitly a hack - but to fix #526045
I^wsomeone will probably have to largely rewrite the dependency parser and
related code anyway...


cheers,
Holger
 
Old 03-01-2011, 08:28 AM
Vincent Danjean
 
Default Are circular dependencies inside a source package OK?

On 27/02/2011 16:31, Lucas Nussbaum wrote:
> But then, we have a problem, because:
> - ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo,
> rubinius-foo) installed to work correctly

I find this dependency tedious. If someone installs ruby-foo, how can
he expect it to work if he does not specify with which ruby interpreter
he will work ?
This means that nothing can 'depend' on ruby-foo without also
depending on a ruby<interpreter_version>-foo

Reading latter, it seems that you want that ruby-foo installs
what it needed for the default ruby implementation. So, do what
Josselin suggests:
- ruby-foo-common: arch indep, no depends (or depends on other software)
- ruby<interpreter_version>-foo: arch dep, Depends: ruby-foo
- ruby-foo: arch indep, empty package, Depends: ruby<default_interpreter>-foo

> - ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo
> installed
>
> What we would like to do to reflect this is:
> - ruby-foo depend on the implementation-specific package for the default
> version of Ruby (so Depends: ruby1.8-foo)
> - ruby<interpreter_version>-foo Depends: ruby-foo

With your proposal, in addition to the circular dependencies, I cannot
install foo for jruby without *also* installing foo for the default
interpreter...

Regards,
Vincent

> However, that creates many small dependency cycles. I am under the
> impression that dependency cycles are considered bad, but that we have
> many of them already, and that no important part of our infrastructure
> or tools really has problems with them. Also, they are limited to a
> single source package here.
>
> Is there a good reason not to do the above?
>
> - Lucas
>
>


--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D6CBC22.6030902@free.fr">http://lists.debian.org/4D6CBC22.6030902@free.fr
 
Old 03-01-2011, 08:44 AM
Bernd Zeimetz
 
Default Are circular dependencies inside a source package OK?

On 02/27/2011 04:31 PM, Lucas Nussbaum wrote:
> Ideally, we would have binary packages named like that:
> ruby-foo: arch-indep part of the foo library
> ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
> ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1

Here you're basically at a point where Python was years ago - one binary
package for every supported version. i think you should find a way to
move the whole stuff for all ruby versions into one package and find a
proper way to handle dependencies and whatever else is needed.

--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D6CC012.1000909@bzed.de">http://lists.debian.org/4D6CC012.1000909@bzed.de
 
Old 03-01-2011, 09:17 AM
Lucas Nussbaum
 
Default Are circular dependencies inside a source package OK?

On 01/03/11 at 10:44 +0100, Bernd Zeimetz wrote:
> On 02/27/2011 04:31 PM, Lucas Nussbaum wrote:
> > Ideally, we would have binary packages named like that:
> > ruby-foo: arch-indep part of the foo library
> > ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
> > ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1
>
> Here you're basically at a point where Python was years ago - one binary
> package for every supported version. i think you should find a way to
> move the whole stuff for all ruby versions into one package and find a
> proper way to handle dependencies and whatever else is needed.

Here we are only discussing Ruby libraries that ship .so files. For
pure-ruby libs (which is the vast majority of ruby libs), we have a
solution already, with only one binary package.

I think it's reasonable to have one package per ruby implementation for
native packages.

- Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110301101724.GA11278@xanadu.blop.info">http://lists.debian.org/20110301101724.GA11278@xanadu.blop.info
 
Old 03-01-2011, 10:49 AM
Bernd Zeimetz
 
Default Are circular dependencies inside a source package OK?

On 03/01/2011 11:17 AM, Lucas Nussbaum wrote:
> On 01/03/11 at 10:44 +0100, Bernd Zeimetz wrote:
>> On 02/27/2011 04:31 PM, Lucas Nussbaum wrote:
>>> Ideally, we would have binary packages named like that:
>>> ruby-foo: arch-indep part of the foo library
>>> ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
>>> ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1
>>
>> Here you're basically at a point where Python was years ago - one binary
>> package for every supported version. i think you should find a way to
>> move the whole stuff for all ruby versions into one package and find a
>> proper way to handle dependencies and whatever else is needed.
>
> Here we are only discussing Ruby libraries that ship .so files.

That shouldn't make a difference if you find a way to handle the
dependencies to whatever they link properly. Unfortunately i don't know
enough about th einternals of Ruby to make a really useful suggestion,
but I'm sure it would be possible to find a proper solution which
doesn't involve a lot of additional packages.

--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D6CDD44.5060909@bzed.de">http://lists.debian.org/4D6CDD44.5060909@bzed.de
 
Old 03-01-2011, 08:35 PM
Dominique Dumont
 
Default Are circular dependencies inside a source package OK?

Le dimanche 27 fvrier 2011 16:31:29, Lucas Nussbaum a crit :
> But then, we have a problem, because:
> - ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo,
> rubinius-foo) installed to work correctly

ok

> - ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo
> installed

Correct me if I'm wrong, but ruby1.8-foo, ruby1.9.1-foo, jruby-foo are not
broken without ruby-foo, they're just useless. So this may be interpreted as
not being a dependency.

Moreover, I have the impression that any ruby package needing foo
*functionality* will depend on ruby-foo and not on any arch/interpreter
specific package. In this case the dependency between ruby1.8-foo, ruby1.9.1-
foo, jruby-foo, rubinius-foo will probably never be actually used ..

Thoughts ?

HTH

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201103012235.46134.domi.dumont@free.fr">http://lists.debian.org/201103012235.46134.domi.dumont@free.fr
 

Thread Tools




All times are GMT. The time now is 07:15 AM.

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