The mechanism to deprecate packages has already been discussed once. The idea was to add a deprecated_packages marker that would 'exclude' the package *and* add a way to force building excluded packages.
From the user point of view, what would happen is that its build would fail with an error message mentioning that (1) the package is deprecated, (2) how to use it anyways and (3) that he won't be able to use it in future releases unless he copies the package definition into its own package sets. After one release cycle, the package could be simply removed from the package sets. If said users The implementation of "forcing the build of packages" was to add them explicitely to the layout: section in autoproj/manifest. That has unintended consequences (https://github.com/rock-core/autoproj/issues/58). I proposed two alternatives in the discussion, but then I and Alex dropped the matter: - add a ! tag in the package name in the layout to say (do it !) - add a forced_packages section to list packages that should be built no matter what Sylvain On Tue, Apr 21, 2015 at 7:58 AM, Janosch Machowinski <[email protected]> wrote: > Hm, > what about moving the package to a "unmaintained" > or "attic" package set ? > Greetings > Janosch > > Am 21.04.2015 um 11:02 schrieb Steffen Planthaber: >> Hi, >> >> I'd recommend to only comment the package out for at least one release >> cycle. This way, the package can be found, in case it is searched for. >> >> Or should we add a "removed_package" type, that instead of downloading >> and building the package only prints a message that the package was >> removed and state its original url? >> >> Steffen >> >> Am 21.04.2015 um 10:50 schrieb Matthias Goldhoorn: >>> On 21.04.2015 10:46, Janosch Machowinski wrote: >>>> Hey, >>>> I got a package that is ancient and outdated. >>>> How is the workflow for dropping it ? >>>> Do a merge request to remove it from the package set ? >>>> Greetings >>>> Janosch >>>> >>> Moin moin, >>> >>> I would recomment to remove it from master but (as long it is not >>> broken) let it active in the release. >>> ..in the package_set >>> >>> >>> Best, >>> Matthias >>> >>> >> > > > -- > Dipl. Inf. Janosch Machowinski > SAR- & Sicherheitsrobotik > > Universität Bremen > FB 3 - Mathematik und Informatik > AG Robotik > Robert-Hooke-Straße 1 > 28359 Bremen, Germany > > Zentrale: +49 421 178 45-6611 > > Besuchsadresse der Nebengeschäftstelle: > Robert-Hooke-Straße 5 > 28359 Bremen, Germany > > Tel.: +49 421 178 45-6614 > Empfang: +49 421 178 45-6600 > Fax: +49 421 178 45-4150 > E-Mail: [email protected] > > Weitere Informationen: http://www.informatik.uni-bremen.de/robotik > > _______________________________________________ > Rock-dev mailing list > [email protected] > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
