You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/12/22 22:15:10 UTC
[ANNOUNCE] Apache::Scoreboard 2:01
The uploaded file
Apache-Scoreboard-2.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/S/ST/STAS/Apache-Scoreboard-2.01.tar.gz
size: 14132 bytes
md5: da1ac25b4821aab7046b2fb3ca893595
This is Apache::Scoreboard for httpd-2.0 (mod_perl 2.0).
You will still need Apache-Scoreboard-0.10 for mod_perl 1.0 and its apps. CPAN
will now always try to install Apache-Scoreboard-2.xx, even when you want it
to install Apache-Scoreboard-0.10. Go and tell CPAN maintainers that you don't
like it and ask them to work on a solution that will allow several generations
of modules with the same name coexist happily on CPAN. Until masses will start
complaining I don't see this being resolved.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: announce-unsubscribe@perl.apache.org
For additional commands, e-mail: announce-help@perl.apache.org
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Montag, 22. Dezember 2003 22:15 schrieb Stas Bekman:
> This is Apache::Scoreboard for httpd-2.0 (mod_perl 2.0).
>
> You will still need Apache-Scoreboard-0.10 for mod_perl 1.0 and its apps.
> CPAN will now always try to install Apache-Scoreboard-2.xx, even when you
> want it to install Apache-Scoreboard-0.10. Go and tell CPAN maintainers
> that you don't like it and ask them to work on a solution that will allow
> several generations of modules with the same name coexist happily on CPAN.
> Until masses will start complaining I don't see this being resolved.
One solution might be to name all version as major.minor and they are
compatible to the previous one if the major number is equal. This sounds like
a good idea in general to me.
But what is wrong with Apache2-Scoreboard? If it does the same as
Apache-Scoreboard the rewrite is not much more as
perl -i -pe 's/Apache::Scoreboard/Apache2::Scoreboard/g' my project files
and otherwise I have to check the code anyway.
One more point if we have a additional namespace Apache2 all new modules and
the one with different versions for mp1 and mp2 can exist on CPAN. That is a
real advantage and the winner over time anyway.
--
Boris
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi guys,
On Mon, 22 Dec 2003, Stas Bekman wrote:
> >>Guys, it's Christmas.
>
> eh? so?
So you could at least mark this thread [OT].
:)
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Stas Bekman <st...@stason.org>.
Jay R. Ashworth wrote:
> On Mon, Dec 22, 2003 at 09:41:29PM +0000, Ged Haywood wrote:
>
>>On Mon, 22 Dec 2003, Stas Bekman wrote:
>>
>>>Jay R. Ashworth wrote:
>>>
>>>>On Mon, Dec 22, 2003 at 01:28:40PM -0800, Stas Bekman wrote:
>>>>
>>>>>>>...
>>
>>Guys, it's Christmas.
eh? so?
> Certainly.
>
> Well, not for another couple days.
>
> But I'm not mad and Stas, and I don't think he's unhappy with me.
>
> We're just bein' geeks.
seconded.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by "Jay R. Ashworth" <jr...@baylink.com>.
On Mon, Dec 22, 2003 at 09:41:29PM +0000, Ged Haywood wrote:
> On Mon, 22 Dec 2003, Stas Bekman wrote:
> > Jay R. Ashworth wrote:
> >> On Mon, Dec 22, 2003 at 01:28:40PM -0800, Stas Bekman wrote:
> >>>>>...
>
> Guys, it's Christmas.
Certainly.
Well, not for another couple days.
But I'm not mad and Stas, and I don't think he's unhappy with me.
We're just bein' geeks.
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
Come see Linux Gazette in our new home: www.linuxgazette.net!
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Stas Bekman <st...@stason.org>.
Jay R. Ashworth wrote:
[...]
> Oh yeah, it was quite clear to me that it was an infrastructural
> problem. But yes, breaking it out into another datum will solve most
> of the problem. I'm still not happy with overloading it into the
> version number rather than the name, but perhaps there are couplings
> between the "internal" (module calling) and "external" (packaging)
> namespaces of which I'm not aware. If so, a pox on the house of
> whomever designed that system.
But in my proposal there is no mentioning of version or name overloading at
all. You can call your modules 0.01 and it should be just fine.
> Sorry to waste your time, Stas.
You aren't, Jay. I just suggest to move that energy into a different plane.
All I want is to see things happening. I've pushed for this and a few other
changes for more than year on p5p and cpan lists, but until end users will not
start complaining en masse to those in charge, I don't see things starting to
move.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by "Jay R. Ashworth" <jr...@baylink.com>.
On Mon, Dec 22, 2003 at 02:35:40PM -0800, Stas Bekman wrote:
> >>what you get back? 2.01. Right? No.
> >
> > Which sort of *makes* my point: they're *two separate modules*.
> > They're not 2 different versions of the same module.
>
> Yes and No, depending on how you look at it.
Yeah. The problem is that the "top" API is (roughly) the same, but the
"bottom" API differs markedly; it's a problem common to all glue.
> >>>If it doesn't depend on the major version of the parent, then this
> >>>entire conversation doesn't apply to that module, no?
> >>
> >>It does if you suggest to deduct which version this module is designed for
> >>from its version number.
> >
> >
> > <sigh>
> >
> > *You* are suggesting that.
> >
> > *I* am suggesting that you deduce it from the *name*. I am saying that
> > you *cannot* reliably deduce it from the version number, precisely
> > because you are *overloading* the version number, giving it semantics
> > it should not have.
>
> OK, right.
>
> The point of my comment in the original announcement wasn't start this thread
> again, but to get things done. The issue with your suggestion is that nowadays
> we hardly ever do things manually, because we use search.cpan.org or CPAN.pm
> to tell us what and where the package is and they will fail to do that the way
> things are today.
"Again"? Oh.
> Here is what needs to be done:
>
> - META.yml needs to support a new key: product_generation, so module authors
> can mark their module with the generations their module support. it should be
> a key/val thing:
>
> product_generation:
> mod_perl: 1.0
>
> a module can define several generations.
>
> - PAUSE indexer needs to index the higher version number for each
> product_generation if such exists and not just the highest number.
>
> - search.cpan.org/CPAN.pm/CPANPLUS aka CPAN clients need to present the
> highest numbers of all available generations, unless you have asked them for a
> specific version. So whenever you ask any of these CPAN clients to give you
> Apache::Scoreboard, they should say,:
>
> oh, dear, looks like I have several matches for this module:
>
> version generation
> Apache::Scoreboard 0.10 mod_perl 1.0
> Apache::Scoreboard 2.01 mod_perl 2.0
>
> which one do you want [2.01]?
>
> - since we don't like propmts CPAN clients should be instrumented to let us
> tell them what's our preferred generations are. I'm not sure about
> search.cpan.org, but for CPAN.pm/CPANPLUS I want to be able to tell these
> tools about my preferences. So if I'm going to build 3rd party tools for
> generation 'mod_perl: 2.0', I'd like to start CPAN.pm like so:
>
> % CPAN_GENERATIONS="mod_perl: 2.0" perl -MCPAN -eshell
>
> or similar.
>
> - PREREQ_PM needs to support ranges, like Module::Build prerequisites do. So
> if Apache::VMonitor for mod_perl 1.0 needs Apache::Scoreboard for mod_perl
> 1.0, it can ask for it:
>
> PREREQ_PM => {
> "Apache::Scoreboard" => "> 0.12, < 2.00",
> }
>
> -------------------
>
> Once all the above is done, authors will need to release updated packages to
> include the updated META.yml with the right generation numbers and Makefile.PL
> PREREQ_PM fixes. And we are all set.
>
> p.s. remember that the discussed issue is *not* a unique to mod_perl problem.
> There are several other modules with the same issue. For example GD, which has
> at least 3 generations on CPAN.
Oh yeah, it was quite clear to me that it was an infrastructural
problem. But yes, breaking it out into another datum will solve most
of the problem. I'm still not happy with overloading it into the
version number rather than the name, but perhaps there are couplings
between the "internal" (module calling) and "external" (packaging)
namespaces of which I'm not aware. If so, a pox on the house of
whomever designed that system.
Sorry to waste your time, Stas.
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
Come see Linux Gazette in our new home: www.linuxgazette.net!
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Stas Bekman <st...@stason.org>.
Jay R. Ashworth wrote:
> On Mon, Dec 22, 2003 at 01:38:17PM -0800, Stas Bekman wrote:
>
>>>The automatic tools don't *have* to: they're *told* which product to
>>>install by a human, no?
>>
>>No, they aren't. In PREREQ_PM in Makefile.PL you specify the minimal version
>>of some module, CPAN/CPANPLUS will bring the latest version which could be
>>quite a wrong choice if there are two generations of this module on CPAN. Here
>>is an example:
>>
>>PREREQ_PM => {
>> "Apache::Scoreboard" => "0.12"
>>}
>>
>>what you get back? 2.01. Right? No.
>
>
> Which sort of *makes* my point: they're *two separate modules*.
> They're not 2 different versions of the same module.
Yes and No, depending on how you look at it.
>>>I believe you've missed my point:
>>>
>>>The way you're doing it, you will have exactly that problem.
>>>
>>>If instead you name your new apache2 compatible thing Apache2::whatever
>>>(*even though the internal naming it carries may be apache:: for
>>>functionality's sake) then they won't conflict. And if the internal
>>>naming depends on the external naming be right, then you have, so far
>>>as I can see, a semi-insoluble problem.
>>
>>Nope. That's a very bad idea. I don't want to go and rewrite all my code to
>>use Apache2::Request and dozens of other modules, which work exactly the same
>>as before, but their guts are different.
>
>
> I *did* say to only change the name on the packaging, no?
Right. Sorry.
>>>>Also I've just released Apache::VMonitor 2.0, which works with both mod_perl
>>>>generations. So should it be called 1.0? 2.0? It just doesn't work.
>>>
>>>
>>>If it doesn't depend on the major version of the parent, then this
>>>entire conversation doesn't apply to that module, no?
>>
>>It does if you suggest to deduct which version this module is designed for
>>from its version number.
>
>
> <sigh>
>
> *You* are suggesting that.
>
> *I* am suggesting that you deduce it from the *name*. I am saying that
> you *cannot* reliably deduce it from the version number, precisely
> because you are *overloading* the version number, giving it semantics
> it should not have.
OK, right.
The point of my comment in the original announcement wasn't start this thread
again, but to get things done. The issue with your suggestion is that nowadays
we hardly ever do things manually, because we use search.cpan.org or CPAN.pm
to tell us what and where the package is and they will fail to do that the way
things are today.
Here is what needs to be done:
- META.yml needs to support a new key: product_generation, so module authors
can mark their module with the generations their module support. it should be
a key/val thing:
product_generation:
mod_perl: 1.0
a module can define several generations.
- PAUSE indexer needs to index the higher version number for each
product_generation if such exists and not just the highest number.
- search.cpan.org/CPAN.pm/CPANPLUS aka CPAN clients need to present the
highest numbers of all available generations, unless you have asked them for a
specific version. So whenever you ask any of these CPAN clients to give you
Apache::Scoreboard, they should say,:
oh, dear, looks like I have several matches for this module:
version generation
Apache::Scoreboard 0.10 mod_perl 1.0
Apache::Scoreboard 2.01 mod_perl 2.0
which one do you want [2.01]?
- since we don't like propmts CPAN clients should be instrumented to let us
tell them what's our preferred generations are. I'm not sure about
search.cpan.org, but for CPAN.pm/CPANPLUS I want to be able to tell these
tools about my preferences. So if I'm going to build 3rd party tools for
generation 'mod_perl: 2.0', I'd like to start CPAN.pm like so:
% CPAN_GENERATIONS="mod_perl: 2.0" perl -MCPAN -eshell
or similar.
- PREREQ_PM needs to support ranges, like Module::Build prerequisites do. So
if Apache::VMonitor for mod_perl 1.0 needs Apache::Scoreboard for mod_perl
1.0, it can ask for it:
PREREQ_PM => {
"Apache::Scoreboard" => "> 0.12, < 2.00",
}
-------------------
Once all the above is done, authors will need to release updated packages to
include the updated META.yml with the right generation numbers and Makefile.PL
PREREQ_PM fixes. And we are all set.
p.s. remember that the discussed issue is *not* a unique to mod_perl problem.
There are several other modules with the same issue. For example GD, which has
at least 3 generations on CPAN.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by "Jay R. Ashworth" <jr...@baylink.com>.
On Mon, Dec 22, 2003 at 01:38:17PM -0800, Stas Bekman wrote:
> > The automatic tools don't *have* to: they're *told* which product to
> > install by a human, no?
>
> No, they aren't. In PREREQ_PM in Makefile.PL you specify the minimal version
> of some module, CPAN/CPANPLUS will bring the latest version which could be
> quite a wrong choice if there are two generations of this module on CPAN. Here
> is an example:
>
> PREREQ_PM => {
> "Apache::Scoreboard" => "0.12"
> }
>
> what you get back? 2.01. Right? No.
Which sort of *makes* my point: they're *two separate modules*.
They're not 2 different versions of the same module.
> > I believe you've missed my point:
> >
> > The way you're doing it, you will have exactly that problem.
> >
> > If instead you name your new apache2 compatible thing Apache2::whatever
> > (*even though the internal naming it carries may be apache:: for
> > functionality's sake) then they won't conflict. And if the internal
> > naming depends on the external naming be right, then you have, so far
> > as I can see, a semi-insoluble problem.
>
> Nope. That's a very bad idea. I don't want to go and rewrite all my code to
> use Apache2::Request and dozens of other modules, which work exactly the same
> as before, but their guts are different.
I *did* say to only change the name on the packaging, no?
> >>Also I've just released Apache::VMonitor 2.0, which works with both mod_perl
> >>generations. So should it be called 1.0? 2.0? It just doesn't work.
> >
> >
> > If it doesn't depend on the major version of the parent, then this
> > entire conversation doesn't apply to that module, no?
>
> It does if you suggest to deduct which version this module is designed for
> from its version number.
<sigh>
*You* are suggesting that.
*I* am suggesting that you deduce it from the *name*. I am saying that
you *cannot* reliably deduce it from the version number, precisely
because you are *overloading* the version number, giving it semantics
it should not have.
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
Come see Linux Gazette in our new home: www.linuxgazette.net!
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by "Jay R. Ashworth" <jr...@baylink.com>.
On Tue, Dec 23, 2003 at 09:38:06AM +0000, Jean-Michel Hiver wrote:
> Say I have an Apache module called Apache::Foo 1.99 and an Apache::Foo
> 2.00 for mod_perl 2. What happens when I want to release a new
> "Apache::Foo 1.99"? Apache::Foo 1.99_01?
>
> Sounds too much like "use 5.008_001' to me, i.e. a big mess :)
>
> So, you've got to change all 'Apache' to 'Apache2' in your Apache2
> modules. Big deal. That's why ctags exist...
And again, I don't want the supplied functions to haev to change names
-- *just* the packaging. But it appears that they;re improperly
conflated by (at least) the CPAN coed (that was a typo, but it's so
damn funny I'm gonna leave it there), and it's unclear whether that's
fixable.
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
Come see Linux Gazette in our new home: www.linuxgazette.net!
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Jean-Michel Hiver <jh...@mkdoc.com>.
> Nope. That's a very bad idea. I don't want to go and rewrite all my code to
> use Apache2::Request and dozens of other modules, which work exactly the same
> as before, but their guts are different.
I would tend to agree with Jay though: I would consider Apache and
Apache2 are two different products. Any trickery with version numbers
for modules is a recipe for disaster.
Say I have an Apache module called Apache::Foo 1.99 and an Apache::Foo
2.00 for mod_perl 2. What happens when I want to release a new
"Apache::Foo 1.99"? Apache::Foo 1.99_01?
Sounds too much like "use 5.008_001' to me, i.e. a big mess :)
So, you've got to change all 'Apache' to 'Apache2' in your Apache2
modules. Big deal. That's why ctags exist...
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi guys,
On Mon, 22 Dec 2003, Stas Bekman wrote:
> Jay R. Ashworth wrote:
>> On Mon, Dec 22, 2003 at 01:28:40PM -0800, Stas Bekman wrote:
>>>>>...
Guys, it's Christmas.
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Stas Bekman <st...@stason.org>.
Jay R. Ashworth wrote:
> On Mon, Dec 22, 2003 at 01:28:40PM -0800, Stas Bekman wrote:
>
>>>>that will allow several generations of modules with the same name
>>>>coexist happily on CPAN. Until masses will start complaining I don't
>>>>see this being resolved.
>>>
>>>Mostly because, IMHO, that is not the proper solution to the problem.
>>>
>>>If you have a dependent subsidiary product which is specific to the
>>>(EG) major revision of some other project, then the first release of
>>>the subsid for the new version should be *1.0*, the *product name*
>>>should be modified to indicate which version of it's parent it applies
>>>to.
>>>
>>>Apache 1 and Apache 2 really *are* two separate parents; encoding your
>>>dependency in *your own* version number is a recipe for pain.
>>
>>Nuh, unfortunately that's not a panacea. None of the automatic tools is able
>>to deduct which version to bring based on the version. And that's where the
>>problem is.
>
>
> The automatic tools don't *have* to: they're *told* which product to
> install by a human, no?
No, they aren't. In PREREQ_PM in Makefile.PL you specify the minimal version
of some module, CPAN/CPANPLUS will bring the latest version which could be
quite a wrong choice if there are two generations of this module on CPAN. Here
is an example:
PREREQ_PM => {
"Apache::Scoreboard" => "0.12"
}
what you get back? 2.01. Right? No.
>>On the manual installation front, yes, you could try to make it easier, by
>>keeping the same major version number. But what if by the time you wanted to
>>release a new version for generation X, that X has already been taken? In any
>>case, it's the automatic dependency resolving tools which we are having the
>>problem with, not the manual ones.
>
>
> I believe you've missed my point:
>
> The way you're doing it, you will have exactly that problem.
>
> If instead you name your new apache2 compatible thing Apache2::whatever
> (*even though the internal naming it carries may be apache:: for
> functionality's sake) then they won't conflict. And if the internal
> naming depends on the external naming be right, then you have, so far
> as I can see, a semi-insoluble problem.
Nope. That's a very bad idea. I don't want to go and rewrite all my code to
use Apache2::Request and dozens of other modules, which work exactly the same
as before, but their guts are different.
>>Also I've just released Apache::VMonitor 2.0, which works with both mod_perl
>>generations. So should it be called 1.0? 2.0? It just doesn't work.
>
>
> If it doesn't depend on the major version of the parent, then this
> entire conversation doesn't apply to that module, no?
It does if you suggest to deduct which version this module is designed for
from its version number.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by "Jay R. Ashworth" <jr...@baylink.com>.
On Mon, Dec 22, 2003 at 01:28:40PM -0800, Stas Bekman wrote:
> >>that will allow several generations of modules with the same name
> >>coexist happily on CPAN. Until masses will start complaining I don't
> >>see this being resolved.
> >
> > Mostly because, IMHO, that is not the proper solution to the problem.
> >
> > If you have a dependent subsidiary product which is specific to the
> > (EG) major revision of some other project, then the first release of
> > the subsid for the new version should be *1.0*, the *product name*
> > should be modified to indicate which version of it's parent it applies
> > to.
> >
> > Apache 1 and Apache 2 really *are* two separate parents; encoding your
> > dependency in *your own* version number is a recipe for pain.
>
> Nuh, unfortunately that's not a panacea. None of the automatic tools is able
> to deduct which version to bring based on the version. And that's where the
> problem is.
The automatic tools don't *have* to: they're *told* which product to
install by a human, no?
> On the manual installation front, yes, you could try to make it easier, by
> keeping the same major version number. But what if by the time you wanted to
> release a new version for generation X, that X has already been taken? In any
> case, it's the automatic dependency resolving tools which we are having the
> problem with, not the manual ones.
I believe you've missed my point:
The way you're doing it, you will have exactly that problem.
If instead you name your new apache2 compatible thing Apache2::whatever
(*even though the internal naming it carries may be apache:: for
functionality's sake) then they won't conflict. And if the internal
naming depends on the external naming be right, then you have, so far
as I can see, a semi-insoluble problem.
> Also I've just released Apache::VMonitor 2.0, which works with both mod_perl
> generations. So should it be called 1.0? 2.0? It just doesn't work.
If it doesn't depend on the major version of the parent, then this
entire conversation doesn't apply to that module, no?
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
Come see Linux Gazette in our new home: www.linuxgazette.net!
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Stas Bekman <st...@stason.org>.
Jay R. Ashworth wrote:
> On Mon, Dec 22, 2003 at 01:15:10PM -0800, Stas Bekman wrote:
>
>>This is Apache::Scoreboard for httpd-2.0 (mod_perl 2.0).
>>
>>You will still need Apache-Scoreboard-0.10 for mod_perl 1.0 and its
>>apps. CPAN will now always try to install Apache-Scoreboard-2.xx, even
>>when you want it to install Apache-Scoreboard-0.10. Go and tell CPAN
>>maintainers that you don't like it and ask them to work on a solution
>>that will allow several generations of modules with the same name
>>coexist happily on CPAN. Until masses will start complaining I don't
>>see this being resolved.
>
>
> Mostly because, IMHO, that is not the proper solution to the problem.
>
> If you have a dependent subsidiary product which is specific to the
> (EG) major revision of some other project, then the first release of
> the subsid for the new version should be *1.0*, the *product name*
> should be modified to indicate which version of it's parent it applies
> to.
>
> Apache 1 and Apache 2 really *are* two separate parents; encoding your
> dependency in *your own* version number is a recipe for pain.
Nuh, unfortunately that's not a panacea. None of the automatic tools is able
to deduct which version to bring based on the version. And that's where the
problem is.
On the manual installation front, yes, you could try to make it easier, by
keeping the same major version number. But what if by the time you wanted to
release a new version for generation X, that X has already been taken? In any
case, it's the automatic dependency resolving tools which we are having the
problem with, not the manual ones.
Also I've just released Apache::VMonitor 2.0, which works with both mod_perl
generations. So should it be called 1.0? 2.0? It just doesn't work.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Stas Bekman <st...@stason.org>.
Richard F. Rebel wrote:
> I didn't put a lot of thought into this but can't the makefile be made
> more intelligent and put *both* versions into the tarball?
> mod_perl-v1-1.9xx-v2-1.99xx.tar.gz
>
> Just an idea that might quickly resolve the issue without the back and
> forth and this and that about who's got the most 'right' solution.
It won't.
- Several packages are maintained by different authors.
- Are you going to make a new release every time one of the generations has a
new release and force folks to upgrade?
- it won't resolve PREREQ_PM issues
- probably a lot more
Believe me, we have already thought of and discussed tones of possible
workarounds, including this one. It's really a waste of time to iterate them
again and again, this issue comes up.
I'd like to repeat that I wasn't asking for ideas in my announce, just asking
to help to ask CPAN maintainers to provide solutions, that they know about
very well.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by "Richard F. Rebel" <rr...@whenu.com>.
I didn't put a lot of thought into this but can't the makefile be made
more intelligent and put *both* versions into the tarball?
mod_perl-v1-1.9xx-v2-1.99xx.tar.gz
Just an idea that might quickly resolve the issue without the back and
forth and this and that about who's got the most 'right' solution.
On Mon, 2003-12-22 at 17:40, Randy Kobes wrote:
> On Mon, Dec 22, 2003 at 01:15:10PM -0800, Stas Bekman wrote:
> > This is Apache::Scoreboard for httpd-2.0 (mod_perl 2.0).
> >
> > You will still need Apache-Scoreboard-0.10 for mod_perl
> > 1.0 and its apps. CPAN will now always try to install
> > Apache-Scoreboard-2.xx, even when you want it to install
> > Apache-Scoreboard-0.10. Go and tell CPAN maintainers that
> > you don't like it and ask them to work on a solution that
> > will allow several generations of modules with the same
> > name coexist happily on CPAN. Until masses will start
> > complaining I don't see this being resolved.
>
> This seems like a difficult problem to solve, in the short
> term - one consideration CPAN must take into account is that
> one doesn't want multiple *non-cooperative* versions of the
> same module which might arise from different people
> unknowingly using the same module name. This could be
> solved by only allowing generations to those registered in
> some group account, but it becomes involved ....
>
> What might help, again for the short term, is some variation
> of the following ... We can't do anything about mod_perl 1
> modules, and there's no problem for packages that work with
> both mod_perl 1 and 2, or have versions bundled in the same
> package for each. So the main problem is for mod_perl 2
> specific modules that have the same name as a previous
> (non-compatible) mod_perl 1 version. What about for these:
>
> - place the modules that conflict with previous mod_perl 1
> modules in some directory that PAUSE won't index. I think
> currently PAUSE ignores a blib/ directory - one could, as a
> hack, use this, and then have Makefile.PL move all the files
> under blib/ into a corresponding lib/ tree. However, it
> might be relatively easy to have the PAUSE maintainers agree
> to some conventional name of a directory that the indexer
> won't descend into. One can use the DIR attribute of
> ExtUtils::MakeMaker to tell WriteMakefile() that modules are
> to be found in this directory.
>
> - for a module, eg, Apache::Foo, in a mod_perl 2 package,
> make up a placeholder like Apache2::Foo that just has a NAME
> pod section, giving the name and abstract of the module, and
> register Apache2::Foo with PAUSE. Apache2::Foo would not
> have any code - it's purpose is just to be used in a
> PREREQ_PM when one wants the mod_perl 2 version of
> Apache::Foo in the mod_perl 2 package. Since the indexer
> hasn't seen the Apache::Foo in the mod_perl 2 package, using
> Apache::Foo in a PREREQ_PM will fetch the older Apache::Foo
> mod_perl 1 version.
>
> --
> best regards,
> randy
--
Richard F. Rebel
rrebel@whenu.com
t. 212.239.0000
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, Dec 22, 2003 at 01:15:10PM -0800, Stas Bekman wrote:
>
>>This is Apache::Scoreboard for httpd-2.0 (mod_perl 2.0).
>>
>>You will still need Apache-Scoreboard-0.10 for mod_perl
>>1.0 and its apps. CPAN will now always try to install
>>Apache-Scoreboard-2.xx, even when you want it to install
>>Apache-Scoreboard-0.10. Go and tell CPAN maintainers that
>>you don't like it and ask them to work on a solution that
>>will allow several generations of modules with the same
>>name coexist happily on CPAN. Until masses will start
>>complaining I don't see this being resolved.
>
>
> This seems like a difficult problem to solve, in the short
> term - one consideration CPAN must take into account is that
> one doesn't want multiple *non-cooperative* versions of the
> same module which might arise from different people
> unknowingly using the same module name. This could be
> solved by only allowing generations to those registered in
> some group account, but it becomes involved ....
Nuh, that's usually not the problem, people tend to cooperate most of the time.
> What might help, again for the short term, is some variation
> of the following ...
[...]
May be. But I'm sick of constantly looking for limping ugly workarounds. In
fact I'm very much against any workarounds, we need to solve the problem, not
work around it. There is a proposal, which is not technically complicated at
all, IMHO of course. It just needs to be implemented. If we provide
workarounds the solution will never be implemented.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, Dec 22, 2003 at 01:15:10PM -0800, Stas Bekman wrote:
> This is Apache::Scoreboard for httpd-2.0 (mod_perl 2.0).
>
> You will still need Apache-Scoreboard-0.10 for mod_perl
> 1.0 and its apps. CPAN will now always try to install
> Apache-Scoreboard-2.xx, even when you want it to install
> Apache-Scoreboard-0.10. Go and tell CPAN maintainers that
> you don't like it and ask them to work on a solution that
> will allow several generations of modules with the same
> name coexist happily on CPAN. Until masses will start
> complaining I don't see this being resolved.
This seems like a difficult problem to solve, in the short
term - one consideration CPAN must take into account is that
one doesn't want multiple *non-cooperative* versions of the
same module which might arise from different people
unknowingly using the same module name. This could be
solved by only allowing generations to those registered in
some group account, but it becomes involved ....
What might help, again for the short term, is some variation
of the following ... We can't do anything about mod_perl 1
modules, and there's no problem for packages that work with
both mod_perl 1 and 2, or have versions bundled in the same
package for each. So the main problem is for mod_perl 2
specific modules that have the same name as a previous
(non-compatible) mod_perl 1 version. What about for these:
- place the modules that conflict with previous mod_perl 1
modules in some directory that PAUSE won't index. I think
currently PAUSE ignores a blib/ directory - one could, as a
hack, use this, and then have Makefile.PL move all the files
under blib/ into a corresponding lib/ tree. However, it
might be relatively easy to have the PAUSE maintainers agree
to some conventional name of a directory that the indexer
won't descend into. One can use the DIR attribute of
ExtUtils::MakeMaker to tell WriteMakefile() that modules are
to be found in this directory.
- for a module, eg, Apache::Foo, in a mod_perl 2 package,
make up a placeholder like Apache2::Foo that just has a NAME
pod section, giving the name and abstract of the module, and
register Apache2::Foo with PAUSE. Apache2::Foo would not
have any code - it's purpose is just to be used in a
PREREQ_PM when one wants the mod_perl 2 version of
Apache::Foo in the mod_perl 2 package. Since the indexer
hasn't seen the Apache::Foo in the mod_perl 2 package, using
Apache::Foo in a PREREQ_PM will fetch the older Apache::Foo
mod_perl 1 version.
--
best regards,
randy
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANNOUNCE] Apache::Scoreboard 2:01
Posted by "Jay R. Ashworth" <jr...@baylink.com>.
On Mon, Dec 22, 2003 at 01:15:10PM -0800, Stas Bekman wrote:
> This is Apache::Scoreboard for httpd-2.0 (mod_perl 2.0).
>
> You will still need Apache-Scoreboard-0.10 for mod_perl 1.0 and its
> apps. CPAN will now always try to install Apache-Scoreboard-2.xx, even
> when you want it to install Apache-Scoreboard-0.10. Go and tell CPAN
> maintainers that you don't like it and ask them to work on a solution
> that will allow several generations of modules with the same name
> coexist happily on CPAN. Until masses will start complaining I don't
> see this being resolved.
Mostly because, IMHO, that is not the proper solution to the problem.
If you have a dependent subsidiary product which is specific to the
(EG) major revision of some other project, then the first release of
the subsid for the new version should be *1.0*, the *product name*
should be modified to indicate which version of it's parent it applies
to.
Apache 1 and Apache 2 really *are* two separate parents; encoding your
dependency in *your own* version number is a recipe for pain.
As is obvious.
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
Come see Linux Gazette in our new home: www.linuxgazette.net!
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html