New pear channel , new issues

Piotr Pokora

New pear channel , new issues
Mon May 05 2008 20:10:04 UTC
Hi!

I managed to setup new pear channel for upcoming MidCOM 2.9 & Midgard 1.9.

Unfortunatelly , all packages need to be re created on new channel.
Simply pear channel server solution copies packages information wherever
it's possible.
In addition, database entries are created without any references. Just
raw new records with
hardcoded data.

I doubt anyone is familiar or very well skilled with pear channel
configuration ( and implementation )
so I didn't want to copy all packages from stable repository, as this
could provide unstable and
difficult to resolve bugs. Positive part is also fact that we may clean
channel a bit.

But the real problem appears with possible upgrades. New packages will
be served from new channel,
so it's impossible to upgrade old packages, and pear doesn't have
'replace' option.

Simply, you can not make clean upgrade because of such errors:

ERROR: pear19.midgard-project.org/fi_protie_navigation: conflicting
files found:
midcom/lib/fi/protie/navigation/config/manifest.inc
(pear.midcom-project.org/fi_protie_navigation)

Should we have *very* smart tool which uninstall old packages?
Or should we install midcom 2.9 ( and later 3.0 ) with completely new
baseinstalldir?
The latter will also force us to manage virtual hosts' static links some
nice way.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
- Report abuse
Tarjei Huse

Re: [midgard-dev] New pear channel , new issues
Tue May 06 2008 08:45:05 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Piotr Pokora wrote:
> Hi!
>
> I managed to setup new pear channel for upcoming MidCOM 2.9 & Midgard 1.9.
>
> Unfortunatelly , all packages need to be re created on new channel.
> Simply pear channel server solution copies packages information wherever
> it's possible.
> In addition, database entries are created without any references. Just
> raw new records with
> hardcoded data.
>
> I doubt anyone is familiar or very well skilled with pear channel
> configuration ( and implementation )
> so I didn't want to copy all packages from stable repository, as this
> could provide unstable and
> difficult to resolve bugs. Positive part is also fact that we may clean
> channel a bit.
>
> But the real problem appears with possible upgrades. New packages will
> be served from new channel,
> so it's impossible to upgrade old packages, and pear doesn't have
> 'replace' option.
>
> Simply, you can not make clean upgrade because of such errors:
>
> ERROR: pear19.midgard-project.org/fi_protie_navigation: conflicting
> files found:
> midcom/lib/fi/protie/navigation/config/manifest.inc
> (pear.midcom-project.org/fi_protie_navigation)
>
> Should we have *very* smart tool which uninstall old packages?
> Or should we install midcom 2.9 ( and later 3.0 ) with completely new
> baseinstalldir?
> The latter will also force us to manage virtual hosts' static links some
> nice way.

Hmm, I think we should use a different baseinstalldir. As long as you
only include midcom from one of the dirs, you should be ok. We will
probably find bugs in Midcom where require assumes that it uses
midcom/lib, but I think those are few and far between so I go for just
using a different baseinstalldir, for example midcom3

PS: The phing command contains a way to build all the packages. Thus you
can do that and then upload them. What would be cool is if you created a
phing command to automaticly upload packages.

Regards,
Tarjei

>
> Piotras
> _______________________________________________
> dev mailing list
> dev@lists.midgard-project.org
> http://lists.midgard-project.org/mailman/listinfo/dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIBl5YVRKCnSvzfIRAg7FAJ9XszKkovDn48X9REDQHVWtoWkH+ACgjej+
PF7M7qt9971MPP1jDodtrhY=
=ewwG
-----END PGP SIGNATURE-----
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
- Report abuse
Tero Heikkinen

Re: New pear channel , new issues
Tue May 06 2008 08:44:20 UTC
Bergie had an idea to build own pear channel solution over some org.openpsa component. I remember that it was products.

I do not know how much work it requires. But in the end the solution should be better than current PEAR channel software.

This PEAR thing is currently a major blocker for 1.9/2.9 testing and developing forward. And same problem will come back with Midcom 3.0. So I propose that we seriously start thinking to make our own component that serves those pear packages.

And if we do it nicely perhaps we can offer an alternative for the Chiara Pear channel software and with that spread the usage of Midgard and Midcom withing open source communities.

Unfortunately I have to say that in next two weeks I have very little time to spare because of the exam season.
- Tero
- Reply
- Report abuse
Piotr Pokora

Re: [midgard-dev] New pear channel , new issues
Tue May 06 2008 09:10:03 UTC
tarjei writes:

>> Should we have *very* smart tool which uninstall old packages?
>> Or should we install midcom 2.9 ( and later 3.0 ) with completely new
>> baseinstalldir?
>> The latter will also force us to manage virtual hosts' static links some
>> nice way.
>
> Hmm, I think we should use a different baseinstalldir. As long as you
> only include midcom from one of the dirs, you should be ok. We will
> probably find bugs in Midcom where require assumes that it uses
> midcom/lib, but I think those are few and far between so I go for just
> using a different baseinstalldir, for example midcom3

midcom3 is yet another issue.
Till then, we need new baseinstalldir for 2.9.

If we one need to have both midcom versions ( 2.8 and 2.9 ) installed we
should use new baseinstalldirs. If not, let's create clever uninstaller.

> PS: The phing command contains a way to build all the packages. Thus you
> can do that and then upload them. What would be cool is if you created a
> phing command to automaticly upload packages.

That should be easy if we can depend on curl extension.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
- Report abuse
Piotr Pokora

Re: [midgard-dev] Re: New pear channel , new issues
Tue May 06 2008 09:15:05 UTC
Tero Heikkinen writes:
> Bergie had an idea to build own pear channel solution over some org.openpsa component. I remember that it was products.
>
> I do not know how much work it requires. But in the end the solution should be better than current PEAR channel software.

This is one problem, and is solved now with new pear channel.
But the real problem ( which doesn't depend on server implementation )
is client side.

midgard19/midcom package doesn't upgrade midcom/midcom package because
both come from different channels.
And of course error is raised because both use the same files and
directories.

Basically we need to duplicate every single package. And what we need is:

* replace option ( like the one used by dpkg )
* conditional require , packageA OR packageB

And we need this in pear's package itself.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
- Report abuse
Piotr Pokora

Re: [midgard-dev] New pear channel , new issues
Tue May 06 2008 09:20:07 UTC
tarjei writes:

BIF ( Before I forget ;)

> PS: The phing command contains a way to build all the packages. Thus you
> can do that and then upload them. What would be cool is if you created a
> phing command to automaticly upload packages.

What about obsolete or old packages?
I see there's net_nemein_calendar and org_openpsa_calendar. Is it OK?
There's pl_olga_mnogosearch. Anyone uses it?

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
- Report abuse
Arttu Manninen

Re: [midgard-dev] Re: New pear channel , new issues
Tue May 06 2008 11:05:03 UTC
Tero Heikkinen wrote:
> Bergie had an idea to build own pear channel solution over some org.openpsa component. I remember that it was products.

In the first developer meeting you were at, June of 2007, I started
writing it. It is - as usual with non-profit work - still in the desktop
drawer, waiting for a new inspiration.

Basically I made only some hours of work for it, but I still have plenty
of ideas for the channel. If I only had the time... Hopefully this
summer gives a break and I can reverse engineer PEAR channel XML and
write the PEAR channel.

Our own PEAR component would make it possible to

1. Easily create new PEAR channels, as they would be just a part of
common MidCOM site structure
2. Generate better RSS e.g. to show the version history written in
documentation/CHANGES of each component (all the developers have
been remembering to write these, HAVEN'T YOU?!? ;)
- I am on behalf of this approach instead of using SVN messages, that
are utterly useless sometimes for composing "What has changed since
1.x" lists
3. Midgard ACL's
4. So much more

Maybe this would be a good test case for writing something for MidCOM 3?

--
Arttu
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
- Report abuse
Piotr Pokora

Re: [midgard-dev] Re: New pear channel , new issues
Tue May 06 2008 11:30:03 UTC
Arttu Manninen writes:
> Our own PEAR component would make it possible to
>
> 1. Easily create new PEAR channels, as they would be just a part of
> common MidCOM site structure

I do not like this idea, unless you really need packages served ( and
identified ) from many
different channels. I would go for it if pear would support kind of
mirror in such cases, where
one package may be installed from one server and upgraded from another one.

Besides, I doubt it's going to be stable for *very* long time.
Well... it could be, only if PEAR API *and implementation* would be
stable and consistent.
Price payed for resolving bugs would be too high for having own channel
implementation.

Now, we need to upload packages again ( which must be done anyway ) ,
and duplicate ( which is ugly ) maintainers accounts.

Piotras

_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
- Report abuse