"R.I.P. Deaddog" <[EMAIL PROTECTED]> writes:
> |>Given that gimp1_3 obsoletes gimp-data-min, and gimp provides
> |>gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I
> |>think that would be a bug in RPM?
> |
> | they both provides/obsoletes it, so there's no bug there.
>
> And I think the gimp-data-min shouldn't be obsoleted/provided by
> gimp1_3, since this is an really old artifact from 1.0-1.2 days.
> If gimp-data-min package still exist for now, it won't conflict with
> gimp1_3, so there's not much point to provide/obsolete gimp-data-min in
> gimp1_3.
>
> |>The main difference between the two lies in other packages'
> requirements. If
> |>gimp-1.2 provides hackgimp, then other packages can depend on hackgimp
> when
> |>they mean "gimp >= 1.1". I don't think this is a good thing. For one, it
> |>pretty much fixes the definition of "hackgimp" to be "gimp >= 1.1"
> forever
> |>(or at least until 1.4 comes out). For another, it's a bit weird
> conceptually
> |>for "hackgimp" to mean "the old 1.1 development tree" rather than "the
> |>current development tree."
> |
> | the point is that we do not want to break updates.
> | we cannot change the past, only the future, so here's the hackgimp
> | definition.
>
> This is true, for gimp 1.2. But for 1.3, I guess we don't need to
> provide/obsolete hackgimp again.
we do want want to keep them.
some day, gimp1_3 will become gimp-1.4.x (or gimp-2.0.x once the troll
on gimp development mls end), and we still want to keep this
historical stuff.
ok the odds're high nobody'll try to update from a so old distro but
the better we can do for updates, the better we will.
now, having buglets in these update facilities can happen.
if so, we'll fix them.
i fixed gimp with andi help
i've yet fixed gimp1_3 since it does not build for now (i've problem
with libtool as %install stage) and since i'm busy with other projects
such as porting our tools to the gtk2 perl binding and using its new
features:
- fix all remaining bugs added by the move
- make sure install stil works
- use size group when needed (eg in menus_launchers.pl) in order to
get rid of bad reports about widget alignment
- use optionmenu rather than comboboxes when needed
- diskdrake, draksec, drakxservices: use GtkTrees instead of
packtables
- drakconnect, drakfloppy : grey hidden stuff instead of inlarging
windows at runtime (idem everywhere needed)
what's more, i would like to:
- fix some bugs in bugzilla
- renew mdk-rpm howto:
o devel provides
o new macros
o lib64
o rpmlint / distriblint
o new auto{req,provides} for perl
o always obsoletes with tag
- fix explanations: move them to explanations.pm, import them into
common and standalone
- fix stock items usage in interactive tools by providing
interactive::{gtk,newt,...} ->ok ->cancel helpers
and i've to do this before going in hollydays.
so if you want me to merge in your changes, explain them and do not do
too intrusive changes such as cleaning the spec by the same way so
that i can see what you do change, since that'll not be my higher
priority ...
> |>>but when do you upload those fixed packages (at least those
> |>>belonging to contribs) ?
> |>
> |>I already uploaded the .spec files, as I explained in the previous
> |>message. I realize that the cooker submission instructions say to
> |>upload the .src.rpm.
> |
> | it would just be easier if you send me the spec files for my packages
>
> Titi, would you mind if I'm submitting changes to you too?
no. but i'll review them
> Beside the stuff Andy mentioned, I have heavily modified quite a lot
> of places so that many old artifacts from 1.1/1.2 days are gone,
i probably won't take them :-(
> and bring back color modules etc.
let see
