[gentoo-dev] merging two packages - upgrade path?

[gentoo-dev] merging two packages - upgrade path?

[Matthias Schwarzott]

Hi there!

This post is about how to create a nice upgrade path when merging two 
packages.
The packages I care about are media-plugins/vdr-streamdev-{client,server}, 
that we wanted to merge into one media-plugins/vdr-streamdev package.


So there seem to be different options:

1. Just create the new packages and do blocks between split and merged 
versions.

vdr-streamdev-client: DEPEND="!media-plugins/vdr-streamdev"
vdr-streamdev-server: DEPEND="!media-plugins/vdr-streamdev"

vdr-streamdev:
DEPEND="!media-plugins/vdr-streamdev-client
		!media-plugins/vdr-streamdev-server"


2. Same as 1, but create dummy ebuilds vdr-streamdev-client-100 and 
vdr-streamdev-server-100:

vdr-streamdev-server-100:
pkg_setup() {
	eerror "Please unmerge vdr-streamdev-server and emerge vdr-streamdev"
	die
}


3. Let the dummy ebuilds RDEPEND/PDEPEND on the merged version.


I think #1 is the default used in the tree. So is there already some better 
way to do it?
#3 offers the easiest upgrade path but keeps useless dummy ebuilds on the 
system.

Regards
Matthias
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Ulrich Mueller]

>>>>> On Thu, 5 Jun 2008, Matthias Schwarzott wrote:

> This post is about how to create a nice upgrade path when merging two 
> packages.
> The packages I care about are media-plugins/vdr-streamdev-{client,server}, 
> that we wanted to merge into one media-plugins/vdr-streamdev package.


> So there seem to be different options:

> 1. Just create the new packages and do blocks between split and merged 
> versions.

> [...]

> 2. Same as 1, but create dummy ebuilds vdr-streamdev-client-100 and 
> vdr-streamdev-server-100:

> pkg_setup() {
> 	eerror "Please unmerge vdr-streamdev-server and emerge vdr-streamdev"
> 	die
> }

With #1 the user will get a message about the blockers immediately.
With #2 his emerge (maybe of many packages) will needlessly die when
it reaches your package.

> 3. Let the dummy ebuilds RDEPEND/PDEPEND on the merged version.

As you said yourself, #3 will result in cruft leftover on the user's
system.

> #1 is the default used in the tree.

With good reason, IMHO. This is a package manager issue which
shouldn't be "solved" by creating strange dummy ebuilds.

Ulrich
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Arun Raghavan]

On Thu, Jun 5, 2008 at 4:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
[...]
>> #1 is the default used in the tree.
>
> With good reason, IMHO. This is a package manager issue which
> shouldn't be "solved" by creating strange dummy ebuilds.

Won't the new portage unmerge-on-blocker feature take care of this now?

Cheers,
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Matthias Schwarzott]

On Donnerstag, 5. Juni 2008, Ulrich Mueller wrote:
> >>>>> On Thu, 5 Jun 2008, Matthias Schwarzott wrote:
> >
> > This post is about how to create a nice upgrade path when merging two
> > packages.
> > The packages I care about are
> > media-plugins/vdr-streamdev-{client,server}, that we wanted to merge into
> > one media-plugins/vdr-streamdev package.
> >
> >
> > So there seem to be different options:
> >
> > 1. Just create the new packages and do blocks between split and merged
> > versions.
> >
> > [...]
> >
> > 2. Same as 1, but create dummy ebuilds vdr-streamdev-client-100 and
> > vdr-streamdev-server-100:
> >
> > pkg_setup() {
> > 	eerror "Please unmerge vdr-streamdev-server and emerge vdr-streamdev"
> > 	die
> > }
>
> With #1 the user will get a message about the blockers immediately.
> With #2 his emerge (maybe of many packages) will needlessly die when
> it reaches your package.
>

With #1 user will get no message, as neither the user nor the package manager 
know of the merged package that should be emerged.

Maybe #2 but without call to die could be used. But that will make the plugin 
go away until user reacts on the instructions.


> > 3. Let the dummy ebuilds RDEPEND/PDEPEND on the merged version.
>
> As you said yourself, #3 will result in cruft leftover on the user's
> system.
>
> > #1 is the default used in the tree.
>
> With good reason, IMHO. This is a package manager issue which
> shouldn't be "solved" by creating strange dummy ebuilds.
>

Matthias

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Rémi Cardona]

Matthias Schwarzott a écrit :
> With #1 user will get no message, as neither the user nor the package manager 
> know of the merged package that should be emerged.

I would do #1 because it's easier to do and it's the Gentoo Way (tm).

Consider writing an upgrade guide and post it on Planet Gentoo and maybe 
on the forums. If it's really important, you might want to get it 
published in the official Gentoo News or the GMN.

If users don't read _any_ of those, then it's not your fault :)

Cheers

-- 
Rémi Cardona
LRI, INRIA
remi.cardona@lri.fr
remi@gentoo.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Matthias Schwarzott]

On Donnerstag, 5. Juni 2008, Rémi Cardona wrote:
> Matthias Schwarzott a écrit :
> > With #1 user will get no message, as neither the user nor the package
> > manager know of the merged package that should be emerged.
>
> I would do #1 because it's easier to do and it's the Gentoo Way (tm).
>
> Consider writing an upgrade guide and post it on Planet Gentoo and maybe
> on the forums. If it's really important, you might want to get it
> published in the official Gentoo News or the GMN.
>
> If users don't read _any_ of those, then it's not your fault :)
>
Well, I dont guess so much users will read it there.

So my newest idea for this is: package.mask the split ebuilds and write a nice 
mask-message once the new ebuild is marked stable.

Matthias
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Ulrich Mueller]

>>>>> On Thu, 5 Jun 2008, Matthias Schwarzott wrote:

>> With #1 the user will get a message about the blockers immediately.
>> With #2 his emerge (maybe of many packages) will needlessly die
>> when it reaches your package.

> With #1 user will get no message, as neither the user nor the
> package manager know of the merged package that should be emerged.

So nothing depends on it that would pull in the new package? Now I see
what your problem is. ;-)

Isn't it possible to package.move -server or -client to the new
package?

Ulrich
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Marius Mauch]

On Thu, 5 Jun 2008 13:44:06 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 5 Jun 2008, Matthias Schwarzott wrote:
> 
> >> With #1 the user will get a message about the blockers immediately.
> >> With #2 his emerge (maybe of many packages) will needlessly die
> >> when it reaches your package.
> 
> > With #1 user will get no message, as neither the user nor the
> > package manager know of the merged package that should be emerged.
> 
> So nothing depends on it that would pull in the new package? Now I see
> what your problem is. ;-)
> 
> Isn't it possible to package.move -server or -client to the new
> package?

Assuming you're talking about "global updates" commands: Don't use it
for this kind of use case. The "move" command just renames a package in
vdb, and using it for anything that goes beyond a simple relocation in
the tree _will_ result in problems later on (we've been there already).

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Enrico Weigelt]

* Matthias Schwarzott <zzam@gentoo.org> schrieb:

Hi,

> This post is about how to create a nice upgrade path when merging two 
> packages.
> The packages I care about are media-plugins/vdr-streamdev-{client,server}, 
> that we wanted to merge into one media-plugins/vdr-streamdev package.

please, please, don't do at it all.

Server vs. clients things should really be separated, and if there's 
shared code between them (eg. proto headers), it should belong to 
another package. We've already got enough blowed-up, fat packages.

Same with the -client / -server useflags: they're just a work around
for certain upstream's crap design - if they really understood the 
concept named "client-server-model", we'd have clean lines and wouldn't
need this at all.

Actually, I didn't check whether the upstream did this mixup or just 
you, so I won't accuse you for that ;P. If it's the upstream's fault, 
please try to stop them.

Yes, I know Gentoo's policy is to stay as near to upstream as 
possible, but there should be a limit. Upstream quality can range
widely, from excellent to crap. Please try to keep the overall
quality as high as possible and leave out the crap.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Matthias Schwarzott]

On Montag, 9. Juni 2008, Enrico Weigelt wrote:
> * Matthias Schwarzott <zzam@gentoo.org> schrieb:
>
> Hi,
>
> > This post is about how to create a nice upgrade path when merging two
> > packages.
> > The packages I care about are
> > media-plugins/vdr-streamdev-{client,server}, that we wanted to merge into
> > one media-plugins/vdr-streamdev package.
>
> please, please, don't do at it all.
>
> Server vs. clients things should really be separated, and if there's
> shared code between them (eg. proto headers), it should belong to
> another package. We've already got enough blowed-up, fat packages.
>
> Same with the -client / -server useflags: they're just a work around
> for certain upstream's crap design - if they really understood the
> concept named "client-server-model", we'd have clean lines and wouldn't
> need this at all.
>
> Actually, I didn't check whether the upstream did this mixup or just
> you, so I won't accuse you for that ;P. If it's the upstream's fault,
> please try to stop them.
>
> Yes, I know Gentoo's policy is to stay as near to upstream as
> possible, but there should be a limit. Upstream quality can range
> widely, from excellent to crap. Please try to keep the overall
> quality as high as possible and leave out the crap.
>

Well, upstream is just one file/package: vdr-streamdev-0.3.4.tgz

All other distros (that I know of) still have only one package for 
vdr-streamdev.
Only gentoo has split this into the client and server parts.

But we want to revert this now, because splitting leads to more maintainance 
effort as both ebuilds are almost the same.

Regards
Matthias
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] merging two packages - upgrade path?

[Enrico Weigelt]

* Matthias Schwarzott <zzam@gentoo.org> schrieb:

> Well, upstream is just one file/package: vdr-streamdev-0.3.4.tgz

What I suspected.

Actually, I'm not interested in that package. Otherwise there
already would be a fork which keeps that separation.

> But we want to revert this now, because splitting leads to more 
> maintainance effort as both ebuilds are almost the same.

If upstream would do it's homework, there would be almost
no ebuild maintenance work at all ;-P


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@lists.gentoo.org mailing list