FAQ

On Tuesday 28 August 2007 12:10:38 am Gregory Beaver wrote:
http://pear.php.net/package/pearweb_phars sorry
okay, thanks.
1) I make the install-pear-nozlib.phar and go-pear.phar
really, i'm most interested in this part. when you create the phar, do
you do so from a CVS tag on your pear repository typically? or when you
say this:
check out
http://cvs.php.net/viewvc.cgi/pear-core/make-installpear-nozlib-phar.php?vi
ew=markup
ah, will do.
We use the current CVS of pear-core to do this installation, and install
released packages.
and do you tag HEAD when doing this? looking in cvs.php.net i see tags for
RELEASE_1_X_X, but i'm not sure if those are pear tags or something else.
so having the code wrapped up in a phar adds an extra level of
indirection between the first couple steps there, as the "original
tarball" would contain a phar file that would then need to be unpacked,
which probably means shuffling a few other of those steps around, which
is kind of what we do with the current php-tarball-bundled-phar. it's a
bit of a pain (esp setting/changing default config options) but it may
be that this is less of a hassle/problematic/human-error-prone in the
long-run than manually tracking the which modules/versions to bundle and
home-rolling our own debian phar files...
You're best to apply patches AFTER installation of PEAR, rather than
modifying the .phar file or the files within each package's internal
tarball. Otherwise you're just asking for trouble.
oh definitely. what i've been trying to determine though is whether there's
a viable third option, which is to not start with the phar at all, but one
step earlier with an CVS export based on a release tag, do the patching then,
and *then* build the phar in the same manner you do, and use the standard
installation logic for installing it at that point. i'm sure the above
reading will prove enlightening in that respect.
Honestly, I don't approve of patching PEAR, this creates a whole set of
possible bugs that make it harder for us to know what code the user
actually has when trying to fix them. If I see an error where the line
number is off from the released version, I bogus it instantly as we
can't support third-party modifications. It's better to push issues you
find back upstream to us so we can fix them.
and you're completely within your rights to do so... in an ideal world, i
agree, and when i'm on top of my game any fixes/enhancements/etc that would
be appropriate to be sent upstream are handled this way. but there are cases
where this is necessary and unavoidable unfortunately. consider a stable
release of a distro like debian or redhat, where maybe security issue X pops
up. unfortunately we don't have the privilege of being able to just "upgrade
to version Y", and must find the specific fix for X and backport it to the
version included in our release.

another example would be needing to change default settings (memory_limit
etc), default include paths, location of config files etc, which may or may
not be something you would want committed in your own tree.

if you're interested in more detail about any diffs that we're currently
maintaining, once i get this installer stuff worked out and pear split off
into its own package we can audit them and determine whether or not any of
them are useful for you... and otherwise you're always within your rights to
tell users who report bugs against pear to report them to their distro first.


thanks
sean

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 5 | next ›
Discussion Overview
grouppear-core @
categoriesphp
postedAug 25, '07 at 10:52p
activeAug 28, '07 at 6:35a
posts5
users2
websitepear.php.net

2 users in discussion

Sean finney: 3 posts Gregory Beaver: 2 posts

People

Translate

site design / logo © 2022 Grokbase