tech-pkg archive

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

Re: 2008Q1 -> current: downgrade

 >> A lot of? Some of you said that PKG_EPOCH can be impelmented in two
 >> hours or so. It's trivial for me to adapt wip/awk-pkgsrc-dewey.
 >> > of effort in to handle real downgrades specially
 >> >       is not worthwhile;
 >> See above about *real* and pkgsrc-dewey downgrades.

> Epochs would not fix the problems you're complaining about, because
> the problems you're complaining about are not caused by upstream
> package versions going backwards.

You again mix two completely different questions.
I repeat them: 1) packages downgrades (older package has grater version
than the latest package has); 2) pkg_epoch as a part of package's version

This "discussion" becomes absolutely useless.  In order to understand
what's your point, I ask you to answer the following questions.


1) downgrades
- Do you think that binary upgrades are important for (some of) pkgsrc users?
- Do you think that pkgsrc should support binary package upgrades
  as well as source-based upgrades?
- Do you think that binary packages upgrades should work using package
- Does "package needs to be upgraded" mean that pkgsrc binary repository
  contains the package with greater version than that of locally installed?
- Does the CHANGES-YYYY file contain an information about packages
  downgrades (see definition above).
- Does packages downgrades break binary upgrade? "Breaks" here means
  that NOT ALL packages installed on user's machine will be upgraded by
  'pkg_chk -ub' or some other tool. Do you think this is normal?
- Is
  clear now?
- Should package downgrades be avoided between pkgsrc stable branches?
- Is there any way in pkgsrc to see where/when downgrades happen?
  Is it normal?
- Do you think that CHANGES-YYYY file is ideal candidate for the
  information about packages downgrades?
- How about fixing "changes-entry" make's target, that is adding to
  CHANGES-YYYY a new flag "Downgraded" in addition to
- What do you think about introducing the CHANGES-YYYYqN?

2) epoch
- Does pkgsrc support the package renaming, that is does binary packages
  repository contain the information about packages
  renamings (1->1) / splittings (1->N) / unitings (N -> 1).
  "Repository" here means the binary packages + pkg_summary.gz file
- Does renaming the pkgsrc package break binary upgrade? "Breaks" here means
  that NOT ALL packages installed on user's machine will be upgraded by
  'pkg_chk -ub' or something similar. Do you think this is normal?
- Does libmaa-1.10.11 -> libmaa1-1.0.0 renaming break binary
  upgrades (see above)
- Do you think 1.0-20080601 looks normal (not ugly)?
- Does epoch approach leads to package renamings?
- Does epoch approach leads to binary upgrade breakages?
- Does epoch solve libmaa-1.10.11 -> libmaa-1:1.0.0 problem?
- Does epoch solve myprog-2:x.y.z -> myprog-3:YYYYMMDD problem?
- How many lines (approcimately) of code is requiered to implement epoch?
- BSD guys love the words "bloat", "overbloated" etc. What is the bloat?
  How many lines of code, in %?

Best regards, Aleksey Cheusov.

Home | Main Index | Thread Index | Old Index