Re: [Fink-devel] Splitting asciidoc package: proper use of Replaces?
On Fri, Jan 29, 2010 at 10:58:51PM -0500, Charles Lepple wrote: On Fri, Jan 29, 2010 at 10:09 PM, Hanspeter Niederstrasser f...@snaggledworks.com wrote: Charles Lepple wrote: The asciidoc package has a self-contained HTML generator, and a2x, an everything-else generator that depends on Docbook and a number of related tools. Currently, the package has a 'Recommends' line for the a2x dependencies, but since Fink doesn't process the Recommends line, I figured it might be best to split that off into an asciidoc-a2x package with proper dependencies. I would also like the splitoff to be installed for users who are upgrading from the old unified package. Should I use Replaces: asciidoc ( 8.4.5-3) in the a2x splitoff, or will that confuse the Fink dependency engine? (I seem to have a way of finding things that work well with apt/dpkg, but not necessarily with Fink.) Are you using the word 'splitoff' in the Fink sense of SplitOff within a parent package (eg libfoo-dev and libfoo-shlibs are splitoffs of the same package libfoo), or describing asciidoc-a2x as a totally separate package independent of the rest of asciidoc? I'm referring to a Fink SplitOff (same info file). ?In the first case, people building the new 'trim' asciidoc will still end up building asciidoc-a2x and pulling its dependencies even if they don't install it (a price to pay with SplitOffs. The dependencies are runtime rather than build-time (that's why I have gotten away with the Recommends field so far). I appreciate the explanation, but I am still curious about the Replaces field - someone who is using a2x from the old unified package shouldn't have it disappear out from under them as part of an upgrade to a split package (independent of whether the split packages come from the same info file, or two separate info files). Replaces is a file-level thing, it allows one package to overwrite specific files in another already-installed one. It does not cause that other package to be uninstalled unless you also specify Conflicts for it. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Splitting asciidoc package: proper use of Replaces?
On Fri, Jan 29, 2010 at 10:09:43PM -0500, Hanspeter Niederstrasser wrote: Charles Lepple wrote: The asciidoc package has a self-contained HTML generator, and a2x, an everything-else generator that depends on Docbook and a number of related tools. Currently, the package has a 'Recommends' line for the a2x dependencies, but since Fink doesn't process the Recommends line, I figured it might be best to split that off into an asciidoc-a2x package with proper dependencies. I would also like the splitoff to be installed for users who are upgrading from the old unified package. Should I use Replaces: asciidoc ( 8.4.5-3) in the a2x splitoff, or will that confuse the Fink dependency engine? (I seem to have a way of finding things that work well with apt/dpkg, but not necessarily with Fink.) Are you using the word 'splitoff' in the Fink sense of SplitOff within a parent package (eg libfoo-dev and libfoo-shlibs are splitoffs of the same package libfoo), or describing asciidoc-a2x as a totally separate package independent of the rest of asciidoc? In the first case, people building the new 'trim' asciidoc will still end up building asciidoc-a2x and pulling its dependencies even if they don't install it (a price to pay with SplitOffs. In the 2nd case, asciidox-a2x would probably Depend on the new trimmed asciidoc, but the trimmed asciidoc would not care whether asciidoc-a2x is around. A possible solution would be to make a new package (whether a self standing package or a SplitOff of another depends on your reasons for doing this) called asciidoc-base, which includes everything that is not a2x, as well as another package (or splitoff) called asciidoc-a2x, and then have the newer revision of the package 'asciidoc' Depends on both those packages. This way someone with the old asciidoc will see the new version and get both -base and -a2x automatically pulled in by the dependency engine. New users will get the option of installing just -base, just -a2x, or both. Package: asciidoc Depends: asciidoc-base, asciidoc-a2x Splitoff: Package: asciidoc-base Depends: whatever Conflicts/Replaces: asciidoc ( 8.4.5-3) Splitoff2: Package: asciidoc-a2x Depends: asciidoc-base (presumably), other stuff Conflicts/Replaces: asciidoc ( 8.4.5-3) You only want Replaces in those two, not Conflicts, otherwise you have a deadlock during upgrade from old asciidoc: when installing new asciidoc, 1) old asciidoc is totally uninstalled, 2) new components are installed (now that the Conflicts pkg is not present), 3) new asciidoc is installed (now that its Depends are satisfied). But if an external package Depends:asciidoc, step 1 can't happen. If you want to split a2x off because it pulls in too many random Dependencies, then make SplitOff2 (-a2x) above be an entire new package with its own .info file. This way, someone building just asciidoc-base will not pull in all those dependencies. That sounds like a cleaner solution. Like it or not, fink is substantially a source distro right now, so dependencies of splitoffs don't need are still a burden. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Splitting asciidoc package: proper use of Replaces?
On Sat, Jan 30, 2010 at 2:15 PM, Daniel Macks dma...@netspace.org wrote: On Fri, Jan 29, 2010 at 10:58:51PM -0500, Charles Lepple wrote: On Fri, Jan 29, 2010 at 10:09 PM, Hanspeter Niederstrasser f...@snaggledworks.com wrote: Charles Lepple wrote: The asciidoc package has a self-contained HTML generator, and a2x, an everything-else generator that depends on Docbook and a number of related tools. Currently, the package has a 'Recommends' line for the a2x dependencies, but since Fink doesn't process the Recommends line, I figured it might be best to split that off into an asciidoc-a2x package with proper dependencies. I would also like the splitoff to be installed for users who are upgrading from the old unified package. Should I use Replaces: asciidoc ( 8.4.5-3) in the a2x splitoff, or will that confuse the Fink dependency engine? (I seem to have a way of finding things that work well with apt/dpkg, but not necessarily with Fink.) Are you using the word 'splitoff' in the Fink sense of SplitOff within a parent package (eg libfoo-dev and libfoo-shlibs are splitoffs of the same package libfoo), or describing asciidoc-a2x as a totally separate package independent of the rest of asciidoc? I'm referring to a Fink SplitOff (same info file). ?In the first case, people building the new 'trim' asciidoc will still end up building asciidoc-a2x and pulling its dependencies even if they don't install it (a price to pay with SplitOffs. The dependencies are runtime rather than build-time (that's why I have gotten away with the Recommends field so far). I appreciate the explanation, but I am still curious about the Replaces field - someone who is using a2x from the old unified package shouldn't have it disappear out from under them as part of an upgrade to a split package (independent of whether the split packages come from the same info file, or two separate info files). Replaces is a file-level thing, it allows one package to overwrite specific files in another already-installed one. It does not cause that other package to be uninstalled unless you also specify Conflicts for it. Right, so I am using Replaces: asciidoc ( 8.4.5-3) in the splitoff to allow it to upgrade over the unified package. Turns out that the only package which depends on asciidoc is cogito, which has been dead for several years. The asciidoc description has been updated to indicate that the a2x command is now in the splitoff. -- - Charles Lepple -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Splitting asciidoc package: proper use of Replaces?
The asciidoc package has a self-contained HTML generator, and a2x, an everything-else generator that depends on Docbook and a number of related tools. Currently, the package has a 'Recommends' line for the a2x dependencies, but since Fink doesn't process the Recommends line, I figured it might be best to split that off into an asciidoc-a2x package with proper dependencies. I would also like the splitoff to be installed for users who are upgrading from the old unified package. Should I use Replaces: asciidoc ( 8.4.5-3) in the a2x splitoff, or will that confuse the Fink dependency engine? (I seem to have a way of finding things that work well with apt/dpkg, but not necessarily with Fink.) -- Charles Lepple -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Splitting asciidoc package: proper use of Replaces?
Charles Lepple wrote: The asciidoc package has a self-contained HTML generator, and a2x, an everything-else generator that depends on Docbook and a number of related tools. Currently, the package has a 'Recommends' line for the a2x dependencies, but since Fink doesn't process the Recommends line, I figured it might be best to split that off into an asciidoc-a2x package with proper dependencies. I would also like the splitoff to be installed for users who are upgrading from the old unified package. Should I use Replaces: asciidoc ( 8.4.5-3) in the a2x splitoff, or will that confuse the Fink dependency engine? (I seem to have a way of finding things that work well with apt/dpkg, but not necessarily with Fink.) Are you using the word 'splitoff' in the Fink sense of SplitOff within a parent package (eg libfoo-dev and libfoo-shlibs are splitoffs of the same package libfoo), or describing asciidoc-a2x as a totally separate package independent of the rest of asciidoc? In the first case, people building the new 'trim' asciidoc will still end up building asciidoc-a2x and pulling its dependencies even if they don't install it (a price to pay with SplitOffs. In the 2nd case, asciidox-a2x would probably Depend on the new trimmed asciidoc, but the trimmed asciidoc would not care whether asciidoc-a2x is around. A possible solution would be to make a new package (whether a self standing package or a SplitOff of another depends on your reasons for doing this) called asciidoc-base, which includes everything that is not a2x, as well as another package (or splitoff) called asciidoc-a2x, and then have the newer revision of the package 'asciidoc' Depends on both those packages. This way someone with the old asciidoc will see the new version and get both -base and -a2x automatically pulled in by the dependency engine. New users will get the option of installing just -base, just -a2x, or both. Package: asciidoc Depends: asciidoc-base, asciidoc-a2x Splitoff: Package: asciidoc-base Depends: whatever Conflicts/Replaces: asciidoc ( 8.4.5-3) Splitoff2: Package: asciidoc-a2x Depends: asciidoc-base (presumably), other stuff Conflicts/Replaces: asciidoc ( 8.4.5-3) If you want to split a2x off because it pulls in too many random Dependencies, then make SplitOff2 (-a2x) above be an entire new package with its own .info file. This way, someone building just asciidoc-base will not pull in all those dependencies. Hanspeter -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Splitting asciidoc package: proper use of Replaces?
On Fri, Jan 29, 2010 at 10:09 PM, Hanspeter Niederstrasser f...@snaggledworks.com wrote: Charles Lepple wrote: The asciidoc package has a self-contained HTML generator, and a2x, an everything-else generator that depends on Docbook and a number of related tools. Currently, the package has a 'Recommends' line for the a2x dependencies, but since Fink doesn't process the Recommends line, I figured it might be best to split that off into an asciidoc-a2x package with proper dependencies. I would also like the splitoff to be installed for users who are upgrading from the old unified package. Should I use Replaces: asciidoc ( 8.4.5-3) in the a2x splitoff, or will that confuse the Fink dependency engine? (I seem to have a way of finding things that work well with apt/dpkg, but not necessarily with Fink.) Are you using the word 'splitoff' in the Fink sense of SplitOff within a parent package (eg libfoo-dev and libfoo-shlibs are splitoffs of the same package libfoo), or describing asciidoc-a2x as a totally separate package independent of the rest of asciidoc? I'm referring to a Fink SplitOff (same info file). In the first case, people building the new 'trim' asciidoc will still end up building asciidoc-a2x and pulling its dependencies even if they don't install it (a price to pay with SplitOffs. The dependencies are runtime rather than build-time (that's why I have gotten away with the Recommends field so far). I appreciate the explanation, but I am still curious about the Replaces field - someone who is using a2x from the old unified package shouldn't have it disappear out from under them as part of an upgrade to a split package (independent of whether the split packages come from the same info file, or two separate info files). Regards, -- - Charles Lepple -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
