tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: revbumps and version sharing



    Date:        Mon, 23 Nov 2009 14:12:11 +0100
    From:        Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
    Message-ID:  <20091123131211.GB11286%britannica.bec.de@localhost>

  | That is supposed to happen, but sometimes a case slips through.

Yes, exactly, people make mistakes - nothing will ever stop that,
however much we might try, which is why I suggested a procedure
that (at least when implemented correctly) would avoid them - not
making all the problems go away, just some PKGREVISION issues.

  | It shouldn't really hurt, the revision is still supposed to be increased
  | only.

That would mean that when a "case slips through" whoever fixes it
knows that in this case (unlike most, or all, others) they're not supposed to
delete PKGREVISION after a version update.

In the case in question, anyone tracking things without PKG_DEVELOPER set
would have seen gcdmaster move from 1.2.2nb6 to 1.2.3nb6 and then down
to 1.2.3  (well, that's what anyone just observing pkgsrc would have
seen, PKG_DEVELOPER, by chance here, prevented  1.2.3nb6 binary package
being produced, if it was set.)

  | There is a supposed to be a list of locations the Makefile.common or
  | whatever is included from.

Where is this list supposed to be?   I'm not a developer, so there's no
need for me to have access if it is somewhere private, but (at least for
cdrdao), I see nowhere that I can observe where that list exists.

Unless it is somewhere private, once again, I appreciate he difference
between "supposed to" and "someone actually did the work", and I know that
things do go wrong, or get forgotten, or ... and that it is pointless
(especially in a volunteer project) to attempt to attribute blame for
any of that.

  | The Developer is supposed to handle that with care.

Good intentions ...

  | IMO trying to automate this is just going to hurt in a different
  | ways not yet to foreseen.

The only automate part that looks tricky, is with pkgtools/revbump - I
haven't looked at that (I have no need for it myself, obviously) to know
how easy, or hard, that might be to fix.

The rest of it looks to be painless - at the worst, if the .if/.endif
guard gets forgotten, we're no worse off than now (and of course, that
will happen) - where it is used, I can't see a downside right now.

If this was tried, and caused problems that are currently unforseen,
deleting it would be fairly easy to accomplish!

kre



Home | Main Index | Thread Index | Old Index