On Thu, Jan 15, 2004 at 09:55:57PM -0500, Koen van der Drift wrote:
>
> As discussed by Dan Macks and myself on the submission tracker (for
> gd-svg-pm), I suggested the following for handling perl modules. Maybe
> it has been discussed previously, and there might be very good reasons
> why it won't work. Feel free to trash it, but be nice :)
>
> Anyway, the idea is to only have info files that are named foo-pm, so
> no versioned packages, even for perl modules that don't need to be
> versioned. When a package needs to be installed, fink checks the perl
> version (XXX) on the system, and builds a package, that will be named
> foo-pmXXX.deb. So the user will end up with the correct version of
> foo-pm for the system just using one info file, and the deb files are
> distributable. All man files, scripts, etc will also end up in the
> correct place. If foo-pm depends on bar-pm, then bar-pm will first be
> installed as bar- pmXXX, etc. As suggested by Dan, the info file could
> have a line that informs if the package is incompatible with a certain
> version of perl.
What happens if there's more than one perl version installed? That's
one major problem with the current situation. Should 'fink install
foo-pm' install foo-pmXXX for all perlXXX present? That's an idea that
has been floated before, and one concern was that when a new perl
version is installed, we'd need to automatically compile and install a
boatload of -pm for it (keep track of, compile, and install all foo-pm
that are installed for the other perls). I'm against such
auto-bloating out of the user's control, but I know others think
keeping all installed perls at the same level of functionality is a
good idea.
The other current user-land problem is the dpkg conflict of bin/ and
man/ drm notes below. The solution I proposed (manpages in a
-pmXXX-doc splitoff that Conflicts/Replaces with all -pmYYY-doc) could
be a problem if fink implicitly treats foo-pm as foo-pmXXX. The list
of YYY becomes set in stone at compile-time. When a new version of
perl is released, rebuilding foo-pm will set a different Conflicts
line into a .deb with the same %r, which is bad. Though having the
.info code for which XXX are known, and so have the maintainer adjust
this and bump %r when he determines that YYY is supported.
dan
> On Jan 13, 2004, at 12:49 AM, Daniel Macks wrote:
>
> >On Mon, Jan 12, 2004 at 11:12:47PM -0500, David R. Morrison wrote:
> >>Daniel Macks <[EMAIL PROTECTED]> wrote:
> >>>On Mon, Jan 12, 2004 at 08:39:20PM -0500, David R. Morrison wrote:
> >>
> >>>>Some pm packages install binaries in /sw/bin and/or man pages in
> >>>>/sw/share/man. If you have different pmXXX packages, they will
> >>>>want to install the same file.
> >>>>
> >>>>One short-term solution to this is to allow foo-pmXXX to replace
> >>>>foo-pmYYY for all the other YYYs.
> >>>
> >>>That means one could never have more than one perl have a given
> >>>module
> >>>at a time.
> >>
> >>Not true. The most common way in fink that "replaces" is used is to
> >>have one package both conflict with and replace another package.
> >>
> >>However, if I simply put "Replaces: bar" into foo.info (wihtout using
> >>Conflicts), then when you install foo.info, dpkg will overwrite any
> >>files
> >>of the same name which belong to bar.
> >>
> >>I did this with a few of the pmXXX packages this morning:
> >>foo-pm560.info
> >>got "Replaces: foo-pm581" whereas foo-pm581.info got "Replaces:
> >>foo-pm560".
> >>This way, the binary files correspond to the most recently installed
> >>version of the package.
> >
> >I just tried this, and it breaks for package removal. I had two
> >packages:
> >
> > foo (replaces bar) the contained %i/bin/{foo,thingy}
> > bar (replaces foo) the contained %i/bin/{bar,thingy}
> >
> >Installing foo gives /sw/bin/{foo,thingy}.
> >Then installing bar gives /sw/bin/{foo,bar,thingy}.
> >Now removing bar removes /sw/bin/thingy.
> >
> >Dpkg doesn't have a memory of what replaced what, so when the
> >replacement thingy is removed it doesn't know to bring back the one
> >that was replaced.
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
