bugGNU Octave - Bugs: bug #57522, "pkg unload" does not...


bug #57522: "pkg unload" does not care for dependencies

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Thu 02 Jan 2020 10:49:12 PM UTC  
Category:  Octave Function Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Fixed Assigned to:  Philip Nienhuis <philipnienhuis>
Originator Name:  Philip Nienhuis Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 03 Feb 2020 11:10:36 PM UTC, comment #33: 

I didn't follow the last patches here, so I don't see where the issue of case sensitivity came up, but yeah, let's discuss that elsewhere. There are already package name comparisons in pkg.m and subfunctions that are case sensitive, so let's not change it buried in a side effect of another unrelated change.

I'm a Unixy person, but I'm in favor of case insensitivity in this matter.

I'll move that to a new bug report.

Mike Miller <mtmiller>
Project Administrator
Mon 03 Feb 2020 10:20:00 PM UTC, comment #32: 

Thanks for review & pushing and polishing the English text, Rik.

Yeah I understand emotions about case :-)  IMO it's unfortunate that Windows completely ignores it in file systems.

Not meant as argument but rather as explanation: my motivation for strcmpi was that this is about package names; do we accept different packages with names that just differ in case? The current convention is that package names are always lowercase, but maybe some day that'll change.
I see no reason for rejecting mixed-case package names other than convention, or maybe a legacy from some restriction in days gone by. But that's just me, and I don't say that convention is bad :-)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Mon 03 Feb 2020 05:48:12 PM UTC, comment #31: 

I pushed the change to use "any (idx)" here: https://hg.savannah.gnu.org/hgweb/octave/rev/f6f9341c46c1.

Turns out there were still stray debug comments ("# keyboard") left in the code.  That was probably my fault so I removed that here: https://hg.savannah.gnu.org/hgweb/octave/rev/a6d57446cdb3.

I made some slight modifications to the NEWS file addition and checked it in here (https://hg.savannah.gnu.org/hgweb/octave/rev/cc0b31003932).  Biggest change was that NEWS now uses Markdown and the delimiter for code segments is the backtick (`) rather than the apostrophe (').  I also wrapped long lines to 72 characters since we have decided on that for the NEWS file in particular, and used two spaces after a period and before the first word of a new sentence.

The last issue, changing pkg to be potentially case insensitive, needs to be decided first at a strategic level.  Is this something we want?  Coders from UNIX-based OS'es would generally say "No".  Coders from MS-based OS'es would generally say "Yes".  If a decision is arrived at then it should be implemented in a single changeset across all the relevant files making up pkg behavior, rather than one changeset at a time.  That is why I decided to use strcmp rather than strcmpi for the time being.

Rik <rik5>
Project Administrator
Sun 02 Feb 2020 01:51:15 PM UTC, comment #30: 

BTW, here's a cset for NEWS, about new pkg.m behavior.

(file #48333)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Sun 02 Feb 2020 01:40:25 PM UTC, comment #29: 


It looks that one of your edits didn't work out well.

You adapted some adittedly convoluted code in get_inverse_dependencies.m around L.45+ into:

        idx = cellfun (@(S) strcmp (S.name, pdep_nm), installed_pkgs_lst);
        installed_pkgs_lst{idx}.invdeps(end+1) = {installed_pkgs_lst{i}.name};

A problem appears if 'idx' happens to contain only zeros (see below). 'idx' is a pointer to an installed dependency in the list of installed packages.
'idx' however is empty if a direct or indirect dependency of some package-to-be-unloaded happens to be not installed. In that case I get an error along the lines of:

error: a cs-list cannot be further indexed
error: called from
    get_inverse_dependencies at line 46 column 55
    unload_packages at line 36 column 22
    pkg at line 534 column 7

I experimented a bit with cell indexing aong the lines of

a = {1 2 3};
a([false false false]) = 6;

and that works OK ('a' remains untouched), but in the pertinent L.47 in get_inverse_dependencies.m it doesn't work as intended.
I avoided this error by wrapping the ensuing assignment in an if construct, as in attached patch.

In addition, you turned the strcmpi call into strcmp; I deliberately used strcmpi to cater for sloppy package developers and/or sloppy package review, and/or maybe to do away with strict capitalization rules for package dependencies in package DESCRIPTION files.

(file #48332)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Tue 28 Jan 2020 07:48:59 PM UTC, comment #28: 

Thanks for pushing, Rik.

I'll prepare a NEWS item to explain pkg.m's changed behavior.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Tue 28 Jan 2020 06:54:00 PM UTC, comment #27: 

I reviewed your patch, made a few changes, and checked it in here https://hg.savannah.gnu.org/hgweb/octave/rev/915b3630eed0.

I was able to simplify some code by changing

cell2mat (cellfun (..., "uniformoutput", false))

to just

cellfun (...)

I also changed loop indices "ii" and "jj" to just "i" and "j".  Not a big deal, but like Mike I also prefer the shorter versions.

Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Sat 25 Jan 2020 07:39:02 PM UTC, comment #26: 

OK, try v4.
(fixed EOLs + stray tabs)

(file #48287)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Sat 25 Jan 2020 06:51:03 PM UTC, comment #25: 

Hang on, the cset has another issue. I'llupload a better one

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Sat 25 Jan 2020 03:24:22 PM UTC, comment #24: 

Thanks for reviewing, unfortunately v2 turned out to be a botched cset, sorry for wasting your time.
(I wonder how that cset became that way)

Attached is v3. I hope all your critique has been met.

For this cset version I rewrote the pkg.m texinfo parts about the 'load' and 'unload' actions, but I'm not a native English speaker so I suppose some improvement might be due there.

As to the multi-line error messages, I learned that formatting using "\" from Rik. But OK, I turned them into a concatenated string, using [...] as it is the format string.

cellfun (... "uni", ...)': also present in scripts/gui/uisetfont.m

On "ii" and "jj": must be a relict from my Fortran 77 time (several decades back) where it was very hard to distinguish "i", "l" and "1" (in capitals) on line printer output and more recently in Octave I got hit by interference with complex variables :-)

(file #48286)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Thu 23 Jan 2020 07:15:29 PM UTC, comment #23: 

I haven't applied and tested this patch yet, but I still see some edits and style problems that need fixing. But this looks much better, much simpler, and the functionality looks right to me. Thank you for pursuing this and cleaning up the code.

  • Please don't delete the texinfo doc string blocks for the private functions 'describe' and 'unload_packages'. Deleted accidentally?
  • Please fix the hyphen typo in the commit message mentioning "get_inverse-dependencies.m".
  • Why force a line break with '@*' in the middle of the text added to the pkg.m doc string? It looks fine to me without it.
  • The 'endfor' in describe.m seems to have been accidentally unindented.
  • We aren't using the 'Author' and 'Created' comments in Octave source files any more, please delete that comment. And the extra line before '@end deftypefn' in the texinfo doc string should be deleted.
  • There are still a few cases of 'cellfun (... "uni", 0)', please expand those to the full syntax.
  • Please use space around the equals sign in expressions like 'for ii = ...'. I'm personally not a fan of variables named 'ii' and 'jj', but that's fine, we have them elsewhere.
  • Error messages should be prefixed with "pkg: ", not "pkg.m: ".
  • Multi-line error messages should be split into concatenated strings with '...', see similar errors in pkg.m and test.m.
Mike Miller <mtmiller>
Project Administrator
Thu 23 Jan 2020 10:35:57 AM UTC, comment #22: 

I suppose a NEWS item to explain pkg.m's changed behavior might be good? I can make s/th up for that.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Wed 22 Jan 2020 11:21:03 PM UTC, comment #21: 

@Mike: can you review second version of patch so this can be applied for 6.1 release?

Rik <rik5>
Project Administrator
Sun 12 Jan 2020 02:29:00 PM UTC, comment #20: 

New cset attached (v2).
AFAICS I've taken care of all your comment, Mike.

(file #48202)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Thu 09 Jan 2020 09:01:59 PM UTC, comment #19: 

I think you've answered my question by saying that yes, there is no need to compute the reverse-dependencies statically in this patch. So it seems like that step can be simplified out of this patch.

Mike Miller <mtmiller>
Project Administrator
Wed 08 Jan 2020 08:01:37 PM UTC, comment #18: 

pkg.m investigates, updates and stores dependencies only when packages are installed, uninstalled and when the database gets rebuilt. In addition it only looks at (references) dependencies when loading packages.
To me that means that exploring, updating and and storing inverse dependencies would ideally be at those same moments, and referencing them when unloading would be symmetric with loading.
Dependencies and inverse dependencies both comprise static package info that doesn't change after installation and can be safely read from the database / cache.

But ... I realized already some time ago that when unloading a global package, pkg.m should also look at local packages that depend on it. The other way round probably isn't needed as I think global package shouldn't depend on local ones in the first place. It would be daft if global packages should not depend on local ones but nevertheless need to store inverse dependencies on local packages in their global cache entry.
I forgot about this but now that you mention ...

So yes, there is a valid motive for on-the-fly computing of inverse dependencies, perhaps until there's a better way of handling the global and local package databases.
One such a way would be to simply do away with the database/cache completely and store all dependency info more explicitly in the package's PACKINFO subdir (i.e., not in the DESCRIPTION file). That would also simplify mxe-octave's step of building binary packages. To that end computing dependencies on the fly would also be handy (and needed).

Does that answer your question? (maybe it raises just more)

As to (..., "UniformOutput", false): AFAICS that isn't anywhere in the Octave style guide, but I'll happily stick to it :-)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Wed 08 Jan 2020 05:37:37 PM UTC, comment #17: 

Did you try computing the reverse-dependencies on the fly for packages as needed, when "pkg unload" is called, before your implementation that calculates them all and stores them in the cache? If there's not that much of a performance hit, I would think it would be better to not add redundant information to the cache file, and just derive the reverse-deps when needed.

If you do need this stored in the cache, have you looked at whether "pkg rebuild" is also affected?

Please use 'cellfun (..., "UniformOutput", false)' instead of your shortcut syntax.

Mike Miller <mtmiller>
Project Administrator
Tue 07 Jan 2020 09:04:01 PM UTC, comment #16: 

I'll upload a new patch soon. ATM my Linux system is broken (no X), so may take some time.
I'll add in a warning for in case 'pkg describe' finds an old local octave-packages file.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Mon 06 Jan 2020 03:35:34 PM UTC, comment #15: 

Hmm, maybe private/get_inverse_dependencies.m should be mentioned in a module.mk file?

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Sun 05 Jan 2020 04:22:39 PM UTC, comment #14: 

Here's a cset against dev Octave along the lines of option A in:

Please review.

(file #48168)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Sat 04 Jan 2020 05:25:41 AM UTC, comment #13: 

There's no reason why there can't be several efforts to implement an improved packaging command interface if people are so motivated.

I think we've gotten a fair consensus on the mailing list that people believe that "pkg unload A" should issue an error message by default if B is loaded and depends on A, and that "pkg unload -nodeps A" should be documented and result in the current behavior, unload A without any regard for dependency information.

Mike Miller <mtmiller>
Project Administrator
Fri 03 Jan 2020 03:34:04 PM UTC, comment #12: 

@JuanPi: I'm happy to help out where I can.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Fri 03 Jan 2020 02:22:28 PM UTC, comment #11: 

@Mike: so much for collaboration interest https://github.com/apjanke/octave-packajoozle/issues/27
I think the unilateral stilistic choices (which aren't only stilistic but rahter constrain the development) are the reason why I would not vouch for pkj to be merged into core. It is a development nightmare, probably worse that the current pkg. I would rather first define a clean functional API for all these tasks, and then build an OOP if needed (Do I see the need?... no). OOP might be better suited for a pkgcreator package (similar to matlab's) where GUI is rather essential.

Back in 2012 we did considerable cleaning up of pkg

For starters, we modularized the tasks, unified the calling structure and the doc system (e.g. and allowing for pkg help install), and we added a couple of functionalities.
Essentially we isolated each task concerns, and pkg became just a single dispatch function.
The effort got demotivated by excesive PET requeriments (the formalities should mnatch the man-power) from the then-OF-chief and stalled whne we faced the lack of dev community interest/support at OctConf.

I would be happy to restart this if we have a team with reasonable expectations and that understand our constraints.

Juan Pablo Carbajal <juanpi>
Project Member
Fri 03 Jan 2020 12:58:28 PM UTC, comment #10: 

Dear JuanPi:
When you call "pkg load",  pkg.m calls its private function load_packages, which in turn calls "load_packages_and_dependencies.m", and in the latter's subfunction "load_package-dirs" on L. 73 you'll see an "if (handle_deps)" if-clause that determines whether the dependencies will be involved.
So the "-nodeps" functionality for "pkg load" is implemented and works; you can easily verify yourself by trying :-)  The fact that it is undocumented is, well, just the next bug; ATM I have spotted about 4 or 5 other pkg.m bugs awaiting sufficient investigation to enter meaningful bug reports; on top of a few I have submitted patches for that are awaiting review.
(BTW I never intended to get drowned in pkg.m bug fixing, honestly :-) )

As to the coding style, I'm probably spoiled by having been exposed too much to kludgy code from interns, some colleagues, etc. :-) (and maybe from myself too)

I do agree that the pkg.m code itself could be improved. E.g., for loops where a cellfun() would do the job better (and avoids debug-stepping through that loop for all 47 packages in the Windows installer); no descriptions of how the private functions are supposed to do what, other than their name; the fact that for many tiny actions the entire installed package databases (local and global) need to be re-read by installed_packages.m and again morphed into something that's easier processed (a big waste of resources IMO); and so on.
As you say, such issues make it hard to find hooks to improve and extend the code, let alone fix bugs.
That said, I think the structure and organization of pkg.m aren't so bad in comparison.

The Pareto principle was probably at work here. My impression is that pkg.m was finished for 80 % and then left alone. You and I know that getting that far probably took 20 % of the time, and polishing the rest would have required the other 80 % but that never happened.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Fri 03 Jan 2020 08:55:27 AM UTC, comment #9: 

@Philip: if nodeps works with load then it is undocumented

               The package manager will disable dependency checking.
               With this option it is possible to install a package even
               when it depends on another package which is not installed
               on the system.  *Use this option with care.*


          Add named packages to the path.  After loading a package it is
          possible to use the functions provided by the package.  For

               pkg load image

          adds the 'image' package to the path.

in contrast with

          Uninstall named packages.  For example,

               pkg uninstall image

          removes the 'image' package from the system.  If another
          installed package depends on the 'image' package an error will
          be issued.  The package can be uninstalled anyway by using the
          '-nodeps' option.

The problem with pkg.m is not functionality, it is horrible code and maintainability and extensibility issues, in short, bad design (I dare say, no desing at all), which is expected on a function(s) that was devloped on the go.

The dependecy dag (no cycles allowed) support logic on the packages dependency. Things like "what should be loaded first?" "what's the shortestpath from package A to package B?" (meaning what's the easiest way to dependecy connect the two packages), "which is the most dependable package?", etc. and one could further depnd the dag to explore function dependecy (as in "which function of package B is used by functions on package A"). Is a very useful data structure that can speed up and organize many tasks. for example, with a dep dag the code for correctly loading dependencies would be like 3 lines (and not the mess that is now), i.e. just traverse the dag from leafs to root.

@Mike: why not allowing to do that? wouldn't be useful for development to actually do this? Maybe one needs and extra flag '-force' to do crazy stuff.

Juan Pablo Carbajal <juanpi>
Project Member
Fri 03 Jan 2020 08:21:29 AM UTC, comment #8: 

OK I'll post in the maintainers list, later today (first some private stuff).

@JuanPi: I think you got it wrong, sorry, there is a working "-nodeps" option for "pkg load".
IMO pkg.m isn't as bad as you might think :-)

As to dependency graphs, what is exactly meant by that?
AFAICS with my suggestion to add reverse dependency info to the octave_packages file(s) the basics for any means to efficiently explore & handle dependencies would be there.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Fri 03 Jan 2020 04:12:03 AM UTC, comment #7: 

Juanpi - have you looked at the DependencyDiagrammer feature in packajoozle?


Maybe you and Andrew can combine your efforts on building package dependency graphs.

Mike Miller <mtmiller>
Project Administrator
Fri 03 Jan 2020 03:42:47 AM UTC, comment #6: 

I think it's clear that some discussion is needed to figure out what behavior is desired. I also think it's clear that the current behavior isn't really breaking anything, that unloading is not used that often, that this isn't blocking any other changes from happening, and that this doesn't urgently need to be addressed for 6.1.0.

I think my preferred behavior would be to issue an error message, treating a package as "resource" that is in use by another package, and only unload A if B is unloaded first or in the same command.

Mike Miller <mtmiller>
Project Administrator
Fri 03 Jan 2020 01:15:52 AM UTC, comment #5: 


1. pkg can check if a package is loaded using the describe option
2. There is no nodeps for loading or unloading, only for installing.
3. One cannot uninstall dependencies, and an error is issued.

I prefer to let the user do what they want (maybe there is a valid use case which devs did not foresee!), and warn them if what they do is not desired.

Juan Pablo Carbajal <juanpi>
Project Member
Fri 03 Jan 2020 12:57:55 AM UTC, comment #4: 

On the main issue of the report: I am for issuing a warning and just unloading the selected package (third form the last item in Mike's list)

But I am not contributing to the discussion on how to handle the behavior of unload, but to the need to store full dependency graph for each package.

I have created a set of functions[1] that can be integrated into pkg, or Andrew's pkj to update dependency information at install time. This info could also be collected as part of the releasing mechanism.
Once we have this info in the packages db file it is a matte rof choosing how to traverse it.
Currently the files gets the info from installed packages, but I will extend it to get the info from a url instead.

So, maybe it is worth adding a true feature request with "pkg build dependency dag" or something on those lines.

[1]: https://gitlab.com/kakila/dependencydag

Juan Pablo Carbajal <juanpi>
Project Member
Fri 03 Jan 2020 12:32:12 AM UTC, comment #3: 

You make it a feature request, but IMO it is a concealed bug. After all, depender packages are affected when unloading their dependencies.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Fri 03 Jan 2020 12:30:04 AM UTC, comment #2: 

Yeah I probably uncovered a can of worms. Unloading a package doesn't happen that often I think, so nobody has thought very deeply about it until now. However, I had to due to other bugs/patches, and I encountered a maze of issues all dealing with dependencies.

IMO a user should at least be notified if he/she wants to unload package "A" but leave its depender "B" loaded. Currently there's no notification (warning or error) at all.
To get this far (that is, before any of your points below) the reverse dependencies first have to be detected. That is step 1.

In addition to your point 1 (error and no unloading), we can:

  • require the "-nodeps" flag to override unloading dependencies but not their dependers. IOW leave the responsibility to the users.

That is not only my preferred solution for now, it also mimics what presently happens when installing, uninstalling *and* loading packages with the "-nodeps" flag: the user should be explicitly aware of a possibly non-optimal result.

As outlined in my last but one paragraph, I think this is all fairly easy to get together, and I think it can be done before a 6.1.0 feature freeze.
What should happen when unloading a pure depender (my point (1) relates to a non-harmful situation and dealing with that can be postponed.

I'd agree that we can ask on the maintainers list what to do next, or if anything needs to be done at all after the above.
I think any of your points 2-7 plus any others not mentioned yet will require more intensive surgery of pkg.m than feasible until the 6.1.0 release. The outcome could become something for Octave-7.x.x

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Thu 02 Jan 2020 11:18:07 PM UTC, comment #1: 

I think it would be very helpful if the first step here were to clearly decide and state what the desired behavior will be. If you need to gather input on the maintainers list, let's do that first.

For example, if the user enters the command "pkg unload A", but package "B" is loaded and depends on "A", what should happen?

I can imagine quite a few possibilities

  • error message, do not unload any packages
  • silently unload both A and B
  • unload both A and B, warning message about B
  • unload A, keep B loaded (current behavior)
  • unload A, keep B loaded, warning message that B may not fully work now
  • unload A, interactive prompt the user what to do with B
  • interactive prompt the user what to do with both A and B

The choice of outcome may depend on whether the user explicitly loaded A or whether A was only implicitly loaded as a dependency of B, or maybe we want a consistent outcome regardless of how A became loaded. We currently do not track the state of whether a package was loaded explicitly or implicitly.

Mike Miller <mtmiller>
Project Administrator
Thu 02 Jan 2020 10:49:12 PM UTC, original submission:  

(see also comments #19-21 of bug #41215)

This bug is actually twofold but the underlying issue is one and the same thing.

(1) "pkg unload" will unload any single package but not its dependencies. In itself this isn't so harmful.

(2) "pkg unload" will happily unload any package even if it's a dependency of one or more other loaded packages that are not called for to be unloaded. This is harmful as it may make those other loaded packages (dependers) fail.

It is easy to see that where pkg.m's private function "load_packages.m" does something with the "handle_deps" input argument, private function "unload_packages.m" completely ignores it.

In my Xmas holiday I had some time to look into this. Based on this I think it shouldn't be too hard to at least get a warning if one or more loaded packages depend on a package-to-be-unloaded, or if a package-to-be-unloaded has dependencies.

What basically needs to be done is either:
- start working on integrating Andrew Janke's packajoozle [1] into Octave (that is, if packajoozle has solid dependency procedures built-in, as I believe is the case)
and/or (maybe for the time being),
- implement two-way dependency info in the octave_packages file (see below).

The latter is superior anyway over the current situation and IMO wouldn't be a very difficult nor a disruptive thing to do.
pkg.m now only stores dependency info at the depender's part of octave_packages. That means that for finding out which other packages depend on some package, each time all packages info has to be traversed. Also storing a list of dependers with each package that is a dependency can easily be done at install time. The resulting octave_packages file would even be backwards-compatible (as it is just a readable .mat type file).

Admittedly this bug might not have a high priority. Users usually just load packages to  get additional functionality. There is little incentive for unloading packages - why would one do that?
But when the patches for "pkg test" get pushed (bug #41215 and bug #41298), it may become more desirable to properly unload packages and their dependencies.

[1] https://github.com/apjanke/octave-packajoozle

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #48333:  NEWS_pkg_behavior_dpendencies.cset added by philipnienhuis (997B - application/octet-stream)
file #48287:  bug_57522_pkg_unload_v4.cset added by philipnienhuis (11KiB - application/octet-stream)
file #48286:  bug_57522_pkg_unload_v3.cset added by philipnienhuis (11KiB - application/octet-stream)
file #48202:  bug57522_pkg_unload_v2.cset added by philipnienhuis (11KiB - application/octet-stream)
file #48168:  bug_57522_pkg-unload.cset added by philipnienhuis (11KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by juanpi (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-03 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2020-02-02 philipnienhuis Attached File- => Added NEWS_pkg_behavior_dpendencies.cset, #48333
    2020-02-02 philipnienhuis Attached File- => Added bug_57522_avoid_unload_error_uninstalled_deps.cset, #48332
        StatusFixed => Patch Submitted
        Open/ClosedClosed => Open
    2020-01-28 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
        Release5.1.0 => dev
    2020-01-25 philipnienhuis Attached File- => Added bug_57522_pkg_unload_v4.cset, #48287
    2020-01-25 philipnienhuis Attached File- => Added bug_57522_pkg_unload_v3.cset, #48286
    2020-01-12 philipnienhuis Attached File- => Added bug57522_pkg_unload_v2.cset, #48202
    2020-01-05 philipnienhuis Attached File- => Added bug_57522_pkg-unload.cset, #48168
        StatusIn Progress => Patch Submitted
    2020-01-04 philipnienhuis StatusNeed Info => In Progress
        Assigned toNone => philipnienhuis
    2020-01-02 mtmiller Severity3 - Normal => 1 - Wish
        Priority5 - Normal => 3 - Low
        Item GroupIncorrect Result => Feature Request
        StatusNone => Need Info

    Back to the top

    Powered by Savane 3.5